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

Ez a referenciaarchitektúra ajánlott alapinfrastruktúra-architektúrát biztosít egy Azure Kubernetes Service-fürt azure-on való üzembe helyezéséhez. A tervezési alapelveket használja, és az Azure Well-Architected Framework architekturális ajánlott eljárásain alapul, hogy egy interdiszciplináris vagy több különböző csapatot, például a hálózatkezelést, a biztonságot és az identitást irányítsa ezen általános célú infrastruktúra üzembe helyezésén keresztül.

Ez az architektúra nem a számítási feladatokra koncentrál, hanem magára az AKS-fürtre koncentrál. Az itt található információk 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, egy többrégiós növekedést támogató hálózati topológia, amely biztosítja a fürtön belüli forgalmat.

A célarchitektúrát az üzleti követelmények befolyásolják, és ennek eredményeként különböző alkalmazáskörnyezetek között változhat. Az üzem előtti és a termelési fázisok kiindulópontjának kell tekinteni.

Az architektúra implementálása a GitHubon is elérhető: Az Azure Kubernetes Service (AKS) alapkonfigurációjának implementálása. Használhatja alternatív kiindulópontként, és igény szerint konfigurálhatja.

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 küllős hálózati topológiát használ. A küllő és a küllő a társviszony-létesítéssel összekapcsolt különálló virtuális hálózatokban van üzembe helyezve. A topológia néhány előnye:

• Szegregált felügyelet. Lehetővé teszi az irányítás alkalmazását és a minimális jogosultság elvének betartását. Emellett támogatja az Azure-beli célzóna fogalmát a feladatok elkülönítésével.

• Minimalizálja az Azure-erőforrások nyilvános interneten való közvetlen kitettségét.

• A szervezetek gyakran regionális küllős topológiákkal működnek. A küllős hálózati topológiák a jövőben bővíthetők, és elkülöníthetők a számítási feladatoktól.

• Minden webalkalmazáshoz webalkalmazási tűzfal (WAF) szolgáltatás szükséges a HTTP-forgalom szabályozásához.

• Természetes választás több előfizetést felölelő számítási feladatokhoz.

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

• Bizonyos erőforrások, például a tűzfal és a DNS megosztható a hálózatok között.

• Igazodik az Azure nagyvállalati szintű kezdőzónáihoz.

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 alapkonfigurációs architektúráján található Windows-tárolók hálózattervezési változásainak áttekintéséhez tekintse át a társcikket.

Hub

A központi virtuális hálózat a kapcsolat és a megfigyelhetőség központi pontja. A központi informatikai csapatok által meghatározott globális tűzfalszabályzatokkal rendelkező Azure Firewall mindig tartalmaz egy azure-tűzfalat, amely kikényszeríti a szervezeti szintű tűzfalszabályzatot, az Azure Bastiont, a VPN-kapcsolatok átjáróalhálózatát, valamint az Azure Monitort a hálózat megfigyelhetősége érdekében.

A hálózaton belül három alhálózat van üzembe helyezve.

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

Az Azure Firewall szolgáltatásként tűzfal. A tűzfalpéldány védi a kimenő hálózati forgalmat. E biztonsági réteg nélkül ez a forgalom egy rosszindulatú külső szolgáltatással kommunikálhat, amely bizalmas vállalati adatokat képes kiszűrni. 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 hálózati architektúratípushoz.

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

Ez az alhálózat egy VPN- vagy 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. A 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ügyelethez és műveletekhez használható.

Beszélt

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ő négy alhálózattal rendelkezik:

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

Az Azure 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 a webalkalmazási tűzfal (WAF) használatát. A WAF biztosítja 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íteni fogja 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 Azure Kubernetes Service-lel (AKS).

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

Az AKS két külön csomópontcsoportot (vagy csomópontkészletet) tart fenn. 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.

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

Azure Private Link-kapcsolatok jönnek létre az Azure Container Registryhez és az Azure Key Vaulthoz, így ezek a szolgáltatások a küllős virtuális hálózaton belüli privát végponttalérhetők el. A privát végpontok nem igényelnek dedikált alhálózatot, és a központi virtuális hálózaton is elhelyezhetők. Az alapkonfigurációban a küllős virtuális hálózaton belül egy dedikált alhálózaton helyezik üzembe őket. Ez a módszer csökkenti a társhálózati kapcsolaton áthaladó forgalmat, megtartja a fürthöz tartozó erőforrásokat ugyanabban a virtuális hálózaton, és lehetővé teszi részletes biztonsági szabályok alkalmazását az alhálózat szintjén 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áshoz tartozó fiók. Az ilyen entitások IP-címei az alhálózati címtérből lesznek lefoglalva. Vegye figyelembe ezeket a pontokat.

• Frissítés

  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.

  Podok esetén 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 lesz szüksége, amíg a tényleges podok frissülnek. 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 lesz szüksége.

  Ebben az architektúrában minden pod közvetlenül is kapcsolatba hozható. Tehát minden podnak egyedi címre van szüksége. A pod méretezhetősége hatással lesz a címszámításra. Ez a döntés attól függ, hogy hány podot szeretne növelni.

• Azure 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. Ebben az architektúrában két cím van hozzárendelve az Azure Container Registryre és a Key Vaultra mutató hivatkozásokhoz.

• Bizonyos címek az Azure számára vannak fenntartva . 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 a rendelkezésre álló 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. Több számítási feladat esetén érdemes elkülöníteni a felhasználói csomópontkészleteket egymástól és a rendszercsomópont-készlettől. Ez a választás 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 alapszintű há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 szempontjainak áttekintéséhez tekintse át a kísérő cikket.

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

A Kubernetes és az AKS folyamatosan fejlődő termékek, gyorsabb kiadási ciklusokkal, mint a helyszíni környezetek szoftverei. 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. A kettő közötti különbség a következő:

• Az AKS csapata az előzetes verziójú funkciókat szállítva és fejlesztve ismerteti. Ennek az az oka, hogy 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 kiadá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. Telepítésüket, konfigurációjukat és életciklusukat az AKS felügyeli.

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 jelennek meg, ez az alaparchitektúra ennek megfelelően módosul. Vannak további előzetes funkciók vagy AKS-bővítmények, amelyeket érdemes lehet kiértékelni az éles üzem előtti fürtökben, amelyek növelik a biztonságot, a kezelhetőséget vagy más követelményeket. Külső 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 behúzza őket a fürtbe.

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

• Ha nyilvános rendszerképet használ, érdemes lehet importálni azt a tárolóregisztrációs adatbázisba, amely megfelel az SLO-nak. Ellenkező esetben előfordulhat, hogy a rendszerkép nem várt rendelkezésre állási problémákat tapasztal. Ezek a problémák működési problémákat okozhatnak, ha a rendszerkép nem érhető el, ha szüksége van rá. A tárolóregisztrációs adatbázis 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.
  • Nem lesznek nyilvános függőségek.
  • 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á.
  • Használja ki az integrált tárolóvizsgálat és a rendszerkép-megfelelőség előnyeit.

  Az egyik lehetőség az Azure Container Registry (ACR).

• 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 architektúra részeként üzembe helyezett ACR-bő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ósrendszer-lemez 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. Minimálisra csökkenti az összes csomóponton futó szolgáltatások, például a monitorozás és a naplózás lábnyomát.

• Helyezzen üzembe legalább két csomópontot. Így a számítási feladat magas rendelkezésre állási mintával fog rendelkezni 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.

• A számítási feladat tényleges csomópontméretei a tervezőcsapat által meghatározott követelményektől függnek. Az üzleti követelmények alapján DS4_v2 választottunk 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.

• A fürt kapacitásának tervezésekor tegyük fel, hogy a számítási feladat az egyes csomópontok legfeljebb 80%-át használhatja fel; 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ú. Gondolja át a fürt szempontjából, amikor biztonsági döntéseket hoz:

• Belső hozzáférés. AKS-hozzáférés az Azure-összetevőkhöz, például a hálózati infrastruktúrához, az Azure Container Registryhez és az Azure Key Vaulthoz. Csak azokat az erőforrásokat engedélyezze, amelyekhez a fürt hozzáfér.
• Külső hozzáférés. Identitások hozzáférésének biztosítása 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.

A két módszer közül a felügyelt identitások használata ajánlott. A szolgáltatásnevek esetében Ön felelős a titkos kódok manuális vagy programozott kezeléséért és elforgatásáért. 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 a felügyelt identitások engedélyezve legyenek, hogy a fürt a Microsoft Entra-azonosítón keresztül kommunikálhasson külső Azure-erőforrásokkal. Ezt a beállítást csak a fürt létrehozásakor engedélyezheti. Még ha nem is használja azonnal a Microsoft Entra-azonosítót, később is beépítheti.

Alapértelmezés szerint két elsődleges identitást használ a fürt, a fürt identitásátés a kubelet-identitást. A fürt identitását az AKS vezérlősík-összetevői használják a fürterőforrások kezelésére, beleértve a bejövő terheléselosztókat, az AKS által felügyelt nyilvános IP-címeket stb. A kubelet-identitás az Azure Container Registry (ACR) használatával történő hitelesítésre szolgál. Egyes bővítmények a felügyelt identitással történő hitelesítést is támogatják.

A belső esethez példaként vizsgáljuk meg a felügyelt identitások használatát, 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. Ennek egyik módja az, hogy ezeket az információkat Kubernetes Titkos kulcsok objektum formájában tárolja, és a titkos kulcs lekérésére használja imagePullSecrets . Ez a megközelítés biztonsági összetettségek miatt nem ajánlott. Nem csak a titkos kód előzetes ismeretére van szüksége, hanem a titkos kód devOps-folyamaton keresztüli felfedésére is. Egy másik ok 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 ezekkel 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 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 által végrehajtani kívánt műveletektő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á lettek rendelve a fürthöz:

• Hálózati közreműködő. A fürt képes vezérelni a küllős virtuális hálózatot. Ez a szerepkör-hozzárendelés lehetővé teszi, hogy az AKS-fürtrendszer hozzárendelt identitása együttműködjön a belső bejövőforgalom-vezérlő szolgáltatásainak dedikált alhálózatával.
• Monitorozási metrikák közzétevője. A fürt metrikákat küldhet az Azure Monitornak.
• AcrPull. A fürt képes lemezképeket lekérni a megadott Azure Container Registriesbő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. Tegyük fel, hogy egy felhasználó kubectl-et szeretne használni. Első lépésként futtatják a az aks get-credentials parancsot a fürt hitelesítő adatainak lekéréséhez. A Microsoft Entra ID hitelesíti a felhasználó identitását a fürt hitelesítő adatainak lekéréséhez engedélyezett Azure-szerepkörökön. További információ: Elérhető fürtszerepkörök engedélyei.

Az AKS kétféleképpen teszi lehetővé a Kubernetes elérését 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 a natív Azure RBAC használata a fürthozzáférés szabályozásához. Mindkettőt az alábbiakban részletezjük.

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

A Kubernetes a szerepköralapú hozzáférés-vezérlést (RBAC) támogatja a következőn keresztül:

• Engedélyek készlete. Fürtszintű engedélyek egy Role vagy ClusterRole objektum által definiálva.

• Olyan kötések, amelyek felhasználókat és csoportokat rendelnek a műveletek elvégzéséhez. Egy vagy ClusterRoleBinding objektum RoleBinding határozza meg.

A Kubernetes rendelkezik néhány beépített szerepkörök, például fürtadminisztrátor, szerkesztés, megtekintés stb. Ezeket a szerepköröket a Microsoft Entra-felhasználókhoz és -csoportokhoz kötheti, hogy vállalati címtárat használjon a hozzáférés kezeléséhez. További információ: Kubernetes RBAC használata a Microsoft Entra-integrációval.

Győződjön meg arról, hogy a fürt- és névtér-hozzáféréshez használt Microsoft Entra-csoportok szerepelnek a Microsoft Entra hozzáférési felülvizsgálataiban.

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

AHelyett, hogy a Kubernetes natív RBAC-t (ClusterRoleBindings és RoleBindings) használnánk az integrált Microsoft Entra-hitelesítéssel való engedélyezéshez, egy másik ajánlott lehetőség az Azure RBAC és az Azure szerepkör-hozzárendelések használata a fürt engedélyezési ellenőrzésének kikényszerítéséhez. Ezek a szerepkör-hozzárendelések akár az előfizetés vagy az erőforráscsoport hatóköreinél is hozzáadhatók, így a hatókörben lévő összes fürt örökli a szerepkör-hozzárendelések konzisztens készletét, tekintettel arra, hogy kinek van engedélye hozzáférni a Kubernetes-fürt objektumaihoz.

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. Az ezzel a módszerrel rendelkező fürtökhöz való felhasználói hozzáférés nem javasolt. Tanúsítványalapú, és az elsődleges identitásszolgáltatón kívül történik; megnehezíti a központosított felhasználói hozzáférés-vezérlést és -szabályozást. A fürthöz való hozzáférést mindig a Microsoft Entra ID használatá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 a fürt üzembe helyezésekor.

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 a ü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 a podok felügyelt identitásait az AKS Microsoft Entra Számítási feladat ID biztosítja. Ez 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 tekintse meg az alábbi áttekintést.

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

A Kubernetes bejövő erőforrásai átirányítják és elosztják a bejövő forgalmat a fürtön. A bejövő erőforrásoknak két része van:

• Belső terheléselosztó. Az AKS felügyeli. Ez 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.

  Ebben az architektúrában az Azure Load Balancert használja a rendszer. A fürtön kívülre kerül egy bejövő erőforrások számára dedikált alhálózatban. Forgalmat fogad Azure-alkalmazás Átjárótól, és ez a kommunikáció TLS-en 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.

• Bejövőforgalom-vezérlő. Traefiket választottuk. 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 ezeket a pontokat.

• A tervezési döntések részeként válasszon egy hatókört, amelyen belül a bejövőforgalom-vezérlő működni fog. 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 a terhelés elterjesztéséhez és az üzletmenet folytonosságának biztosításához, ha egy csomópont leáll. 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 Azure-alkalmazás Átjárótól fogad forgalmat.

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

• 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. Ez a korlátozás a Kubernetes RBAC-engedélyekkel valósítható meg. Ebben az architektúrában például a Traefik engedélyt kapott 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 alapszintű referenciaarchitektúráján a Windows-tárolókban használt bejövő forgalomterv áttekintéséhez tekintse meg a kísérő cikket.

Ú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 jelzi, hogy az útvonalak HTTPS-en keresztül lesznek kiszolgálva. Ez middlewares azt határozza meg, hogy csak a Azure-alkalmazás Átjáró 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ítja a TLS-t, 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 a kontextusban a hálózati folyamat a következőképpen kategorizálható:

• Bejövő forgalom. Az ügyféltől a fürtben futó számítási feladatig.

• Kimenő forgalom. A fürt egyik podjától vagy csomópontjától egy külső szolgáltatásig.

• Pod-pod forgalom. Podok közötti kommunikáció. 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, akkor az alkalmazások közötti kommunikáció ebbe a kategóriába tartozik.

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

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 kódfoltokkal. A szigorú kiszolgálónév-jelzés (SNI) 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 a képen 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 rekordon keresztül van társítva a Azure-alkalmazás 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 (WAF) rendelkezik, és egyezteti a TLS-kézfogást bicycle.contoso.com, így csak biztonságos titkosítást tesz lehetővé. Az Application Gateway egy TLS-végpont, mivel waf-ellenőrzési szabályok feldolgozására és a forgalmat a konfigurált háttérrendszerre továbbítja útválasztási szabályok végrehajtásához szükséges. A TLS-tanúsítvány az Azure Key Vaultban van tárolva. A hozzáférés az Application Gatewayrel integrált, felhasználó által hozzárendelt felügyelt identitással érhető el. Erről a funkcióról további információt a Key Vault-tanúsítványokkal való TLS-megszüntetés című témakörben talál.

3. Ahogy a forgalom az Application Gatewayről a háttérrendszerre kerül, a rendszer újra titkosítja egy másik TLS-tanúsítvánnyal (a *.aks-ingress.contoso.com helyettesítő karakterével), amint a rendszer a belső terheléselosztónak továbbítja. Ez az újratitkosítás gondoskodik arról, 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 a *.aks-ingress.contoso.com számára, és HTTP-en keresztül továbbítja a forgalmat a számítási feladat podjaira. A tanúsítványok az Azure Key Vaultban vannak tárolva, és a Tárolótároló-illesztő (CSI) illesztőprogram használatával vannak csatlakoztatva a fürthöz. További információ: Titkos kódkezelés hozzáadása.

A teljes körű TLS-forgalmat minden ugráskor implementálhatja a számítási feladat podjához vezető úton. Győződjön meg arról, hogy méri a teljesítményt, a késést és a működési hatást a podok közötti forgalom védelmére vonatkozó döntés meghozatalakor. 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űzfal (WAF) használatával történő védelem. Ez minimalizálja a számítási feladatok kezelésével és a hálózati teljesítményre gyakorolt hatásokkal járó többletterhelést. A számítási feladatokra és a megfelelőségi követelményekre vonatkozó 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ürtről érkező kimenő forgalom az Azure Firewallon vagy a saját hasonló hálózati virtuális berendezésén keresztül kommunikáljon más lehetőségeken, például NAT Gatewayen vagy HTTP-proxyn keresztül. A megbízhatóság nélküli vezérlés és a forgalom vizsgálatának lehetősége érdekében a fürtből érkező összes kimenő forgalom az Azure Firewallon halad át. Ezt a választási lehetőséget felhasználó által megadott útvonalakkal (UDR-ekkel) valósíthatja meg. Az útvonal következő ugrása az Azure Firewall privát IP-címe . Itt 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 használatának alternatívája az AKS HTTP-proxy funkciójának használata. A fürtöt kimenő összes forgalom először a HTTP-proxy IP-címére van beállítva, amely úgy dönt, hogy továbbítja vagy elveti a forgalmat.

Bármelyik módszerrel áttekintheti az AKS-hez szükséges kimenő hálózati szabályokat .

A megbízhatóság nélküli vezérlés alól kivételt képez, ha a fürtnek más Azure-erőforrásokkal kell kommunikálnia. A fürtnek például le kell vennie egy frissített lemezképet a tárolóregisztrációs adatbázisból, vagy titkos kulcsokat kell lekérnie az Azure Key Vaultból. Az ajánlott módszer az Azure Private Link használata. Ennek az az előnye, hogy az egyes alhálózatok közvetlenül érik el a szolgáltatást a fürt és az interneten keresztüli szolgáltatások közötti forgalom helyett. Hátránya, hogy a Private Linknek további 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ékváltozat támogatja a Private Linket. Ezekben az esetekben érdemes engedélyezni egy virtuális hálózati szolgáltatásvégpontot 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 fog áthaladni, ezek a címek hozzáadhatók a szolgáltatás IP-engedélyezési listájához. Ennek egyik hátránya, hogy az Azure Firewallnak további szabályokkal kell rendelkeznie ahhoz, hogy csak egy adott alhálózatból érkező forgalom legyen engedélyezve. 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: A kimenő forgalom korlátozása és szabályozása.

Az AKS alapszintű referenciaarchitektúráján a Windows-tárolókban használt Windows-specifikus kimenő forgalom szempontjainak áttekintéséhez tekintse át a kísérő cikket.

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 a podok közötti hálózati forgalom korlátozására szolgál. Alkalmazza a szabályzatokat megfontoltan, ellenkező esetben 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 adhatók hozzá. A implementálható NetworkPolicytechnológiák közül néhányat választhat. Az Azure Network Policy használata javasolt, amelyhez Azure Container Networking Interface (CNI) szükséges, lásd az alábbi megjegyzést. Más lehetőségek közé tartozik a Calico Network Policy, 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 Network Policy és a Calico-szabályzatok és azok képességei 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 fogad forgalmat, amelyek felügyeleti műveleteket szeretnének végezni a fürtön, például erőforrások létrehozására irányuló kérések vagy a fürt méretezése. Ilyen erőforrások például a DevOps-folyamat buildügynökkészlete, egy Bastion-alhálózat és maguk a csomópontkészletek. Ahelyett, hogy minden IP-címről elfogadná ezt a felügyeleti forgalmat, az AKS Engedélyezett IP-tartományok funkciójával csak az engedélyezett IP-tartományokból az API-kiszolgálóra érkező forgalmat engedélyezheti.

További információt az API-kiszolgáló által engedélyezett IP-tartományok definiálása című témakörben talál.

Egy további szabályozási réteg esetében a további összetettség árán létrehozhat egy 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 ne legyen elérhető az interneten. További információ: AKS Private Clusters.

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

Titkos kulcsokat tárol egy felügyelt kulcstárolóban, például az Azure Key Vaultban. Ennek az az előnye, hogy a felügyelt tároló kezeli a titkos kulcsok rotálását, erős titkosítást biztosít, hozzáférési naplót biztosít, és az alapvető titkos kulcsokat az üzembehelyezési folyamaton kívül tartja. Ebben az architektúrában az Azure Key Vault tűzfala engedélyezve van, és privát kapcsolati kapcsolatokkal van konfigurálva az Azure-beli erőforrásokhoz, amelyeknek titkos kulcsokhoz és tanúsítványokhoz kell hozzáférnie.

Az Azure 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. Arról, hogy Azure-alkalmazás átjáró 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 kulcsainak 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 Azure Key Vault az RBAC használatával.

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

Számítási feladatidentitásokat kell használnia ahhoz, 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őt. Ha 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. Ebben a megvalósításban az Azure Key Vaultot választottuk titkos kulcstárolós CSI-illesztőprogrammal a bővítmény használatával, hogy lekérjük a TLS-tanúsítványt az Azure Key Vaultból, és betöltsük a bejövőforgalom-vezérlőt futtató podba. Ez a pod létrehozása során 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úrában használt számítási feladat állapot nélküli. Ha állapotot kell tárolnia, ajánlott a fürtön kívül is tárolni. A számítási feladatok állapotára vonatkozó útmutató nem tartozik a jelen cikk hatókörébe.

A tárolási lehetőségekről további információt az Azure Kubernetes Service (AKS) alkalmazásainak tárolási lehetőségei című témakörben talál.

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 OPA Gatekeeperen keresztül valósítja meg a szabályzatokat. Az AKS-hez a szabályzatok az Azure Policyn keresztül érhetők el. Minden szabályzat a hatókörében lévő összes fürtre vonatkozik. Az Azure Policy kikényszerítését végül az OPA Gatekeeper kezeli a fürtben, és minden szabályzat-ellenőrzést naplóz. A szabályzatmódosítások nem jelennek meg azonnal a fürtön, és várhatóan késni fog.

Az Azure Policy két különböző forgatókönyvet kínál az AKS-fürtök kezeléséhez:

• Az AKS-fürtök erőforráscsoportban vagy előfizetésben való üzembe helyezésének megakadályozása vagy korlátozása a szervezeti szabványok kiértékelésével. Kövesse például az elnevezési konvenciók egyikét, adjon meg egy címkét stb.
• 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 kiválasztja az egyes szabályzatokat? 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 további szabályzatokat a fürthöz és a fürttel interakcióban lévő erőforrásokhoz (ACR, Application Gateway, Key Vault stb.) a szervezet igényeinek megfelelően.

• 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. A nem megfelelő állapotok rendszeres időközönként történő ellenőrzésére és a szükséges lépések meghozására szolgáló folyamatokkal rendelkezhet. 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. Az egyéni szabályzatok létrehozásával kapcsolatos további információkért lásd: 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.

• Az Azure-szabályzatok adott hatókörökhöz vannak rendelve. Győződjön meg arról, hogy az éles szabályzatok az éles üzem előtti környezettel is érvényesítve vannak. Ellenkező esetben az éles környezetben való üzembe helyezéskor váratlan további korlátozásokba ütközhet, amelyek nem voltak figyelembe véve az éles üzem előtti környezetben.

Ebben a referencia-implementációban az Azure Policy engedélyezve van az AKS-fürt létrehozásakor, és naplózási módban rendeli hozzá a korlátozó kezdeményezést, hogy betekintést nyerjen a meg nem felelésbe.

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 ACR-bő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ürtön belülről, elérheti a névtér összes gatekeeper-system podjának podnaplóit, valamint a azure-policy névtérben lévő kube-system podok és azure-policy-webhook podok naplóit.

Az AKS alapszintű referenciaarchitektúráján a Windows-tárolókban szereplő, Windows-specifikus Azure Policy-szempontok áttekintéséhez tekintse át a kísérő cikket.

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

A növekvő igényeknek megfelelően a Kubernetes horizontálisan horizontális podok automatikus skálázásával (HPA) horizontálisan felskálázhatja a meglévő csomópontokat. Ha további podok már nem ütemezhetők, 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.

A manuális vagy programozott módon monitorozni és beállítani kell a cpu-kihasználtságra vagy az egyéni metrikákra vonatkozó riasztásokat. Podméretezés esetén 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 az egyik módszer, ha értesítést kap, 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 a portálon módosíthatja.

Az automatikus skálázás az ajánlott módszer, mivel ezek közül néhány manuális mechanizmus az automatikus skálázóba van beépítve.

Általános megközelítésként kezdje a teljesítménytesztelést minimális számú pod és csomópont használatá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 ajánlott beállítani a replikák minimális és maximális számát. Ezek az értékek korlátozzák az automatikus skálázási korlátokat.

A HPA a processzorkihasználtság, a memóriahasználat és az egyéni metrikák alapján skálázható. Csak a processzorkihasználtság van megadva a dobozon kívül. A HorizontalPodAutoscaler definíciója a metrikák célértékeit határozza meg. A specifikáció például egy cél CPU-kihasználtságot állít be. Miközben a podok futnak, a HPA-vezérlő a Kubernetes Metrics API-val ellenőrzi az egyes podok cpu-kihasználtságát. Összehasonlítja ezt az értéket a célkihasználtsággal, é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, hogy a skálázási művelet befejeződik-e. Az eredmény helytelen arányszámítás lehet. További részletekért lásd a skálázási események hűtését.

Ha a számítási feladat eseményvezérelt, népszerű nyílt forráskódú lehetőség a KEDA. Vegye figyelembe a KEDA-t, ha a számítási feladatot egy eseményforrás, például üzenetsor vezérli ahelyett, hogy cpu- vagy memóriaalapú. A KEDA számos eseményforrást (vagy skálázót) támogat. A támogatott KEDA-skálázók listáját itt találja, beleértve az Azure Monitor-skálázót is; ezzel kényelmesen skálázhatja a KEDA-számítási feladatokat az Azure Monitor-metrikák alapján.

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. A fürt kiépítése során hozzá kell adni. Minden felhasználói csomópontkészlethez külön fürt automatikus skálázására van szükség.

A fürt automatikus skálázását a Kubernetes ütemezője aktiválja. 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 a számítási feladat egyszerű jellege miatt 2..

A rendszercsomópont-készlet esetében a javasolt minimális érték 3.

Az AKS alapkonfigurációs architektúráján található Windows-tárolók skálázási szempontjainak áttekintéséhez tekintse meg a kísérő cikket.

Ü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 szolgáltatásiszint-szerződését. A havi üzemidő-számítással kapcsolatos információkért tekintse meg az Azure Kubernetes Service (AKS) SLA-ját.

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 leáll, az ugyanabban a fürtben lévő csomópontkészlet egy másik csomópontja továbbra is futtathatja az alkalmazást. A megbízhatóság érdekében három csomópont ajánlott a rendszercsomópont-készlethez. A felhasználói csomópontkészlet esetében legalább két csomóponttal kell kezdődnie. Ha magasabb rendelkezésre állásra van szüksége, további csomópontokat építhet ki.

Az alkalmazás(ok) elkülönítése a rendszerszolgáltatásoktól egy külön csomópontkészletben, más néven felhasználói csomópontkészletben való elhelyezésével. Így a Kubernetes-szolgáltatások dedikált csomópontokon futnak, és nem versenyeznek a számítási feladattal. Címkék, címkék és taintek használata ajánlott a csomópontkészlet azonosításához a számítási feladat ütemezéséhez, és győződjön meg arról, hogy a rendszercsomópont-készletet a CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools) címkével fertőzötte meg.

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. A podok állapotának mintavételeken keresztüli monitorozása is ajánlott.

Pod rendelkezésre állása

Győződjön meg a poderőforrásokról. Erősen ajánlott, hogy az üzemelő példányok poderőforrás-követelményeket határozzanak meg. Az ütemező ezután megfelelően ütemezheti a podot. A megbízhatóság jelentősen elavult, 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. Tervezett események, például frissítések és frissítések esetén a megszakítási költségvetés biztosíthatja, hogy a podreplikák szükséges száma létezhessen az alkalmazás várható terhelésének kezeléséhez.

Erőforráskvótákat állíthat be a számítási feladatok névterén. A névtér erőforráskvótája biztosítja, hogy a podkérelmek és a korlátok megfelelően legyenek beállítva az ü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. Ezeknek a korlátoknak a beállítása lehetővé teszi, hogy a Kubernetes hatékonyan lefoglalja a processzor- és/vagy memóriaerőforrásokat a podokhoz, és nagyobb tárolósűrűséget biztosít egy csomóponton. A korlátok a nagyobb hardverkihasználtság miatt csökkenthetik a megbízhatóságot is.

A korlátok 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.

Ezek a korlátok megadhatók az üzembehelyezési jegyzékekben. 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

Ha az SLA magasabb üzemidőt igényel, a rendelkezésre állási zónák használatával védekezhet a kimaradások ellen. A rendelkezésre állási zónákat akkor használhatja, 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. A méretezési csoport műveleteit és konfigurációját az AKS szolgáltatás felügyeli. A többzónás környezet engedélyezésekor az alábbiakat érdemes figyelembe venni:

• 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 és régió rendelkezésre állása. Ha uptime SLA-t szeretne vásárolni, válasszon egy régiót, amely támogatja ezt a lehetőséget. 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ák csak a csomópontkészlet létrehozásakor állíthatók be, és 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öbbzónás támogatás 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 elterülnek a rendelkezésre állási zónák között.

• Függő erőforrások. A teljes zonális előny érdekében 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 miatt a szolgáltatás meghiúsul.

Egy felügyelt lemez például abban a zónában érhető el, amelyben ki van építve. Hiba esetén előfordulhat, hogy a csomópont másik zónába költözik, de a felügyelt lemez nem fog a csomóponttal együtt a zónába lépni.

Az egyszerűség kedvéért ebben az architektúrában az AKS egyetlen régióban van üzembe helyezve, ahol az 1., 2. és 3. rendelkezésre állási zónán átívelő csomópontkészletek találhatóak. 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öbbzónás támogatással. A georeplikálás engedélyezve van az Azure Container Registryben.

Több régió

A rendelkezésre állási zónák engedélyezése nem lesz elég, ha a teljes régió leáll. A magasabb rendelkezésre állás érdekében futtasson több AKS-fürtöt különböző régiókban.

• Párosított régiók használata. Fontolja meg egy CI/CD-folyamat használatát, amely úgy van konfigurálva, hogy párosított régiót használjon a régióhibák utáni helyreállításhoz. A párosított régiók használatának egyik előnye a frissítések során a megbízhatóság. Az Azure gondoskodik arról, hogy egyszerre csak egy régió legyen frissítve a párban. Bizonyos DevOps-eszközök, például a Flux megkönnyítik a többrégiós telepítéseket.

• Ha egy Azure-erőforrás támogatja a georedundanciát, adja meg azt a helyet, ahol a redundáns szolgáltatás másodlagos lesz. Az Azure Container Registry georeplikálásának engedélyezése például automatikusan replikálja a rendszerképeket a kiválasztott Azure-régiókba, és továbbra is hozzáférést biztosít a képekhez, még akkor is, ha egy régió kimaradásban volt.

• 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 az Azure Load Balancert, mert képes a nem webes forgalom zónák közötti elosztására. Ha régiók közötti forgalmat kell elosztania, érdemes megfontolni az Azure Front Door használatát. További szempontokat a Terheléselosztó kiválasztása című témakörben talál.

Vészhelyreállítás

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

• Párosított régiók használata.

• A nem állapotalapú számítási feladatok hatékonyan replikálhatók. Ha az állapotot a fürtben kell tárolnia (nem ajánlott), győződjön meg arról, hogy gyakran készít biztonsági másolatot az adatokról a párosított 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 a szolgáltatásiszint-célkitűzések (SLO) elérése érdekében.

• Az egyes Azure-szolgáltatások kiépítésekor válassza ki a vészhelyreállítást támogató funkciókat. Ebben az architektúrában például az Azure Container Registry engedélyezve van a georeplikáláshoz. Ha egy régió leáll, akkor is lekérhet képeket a replikált régióból.

Fürt biztonsági mentése

Számos architektúra esetén egy új fürt üzembe helyezése és az üzemeltetési állapotba való visszatérése GitOps-alapú [Fürt bootstrapping}(#cluster-bootstrapping) használatával, majd az alkalmazás üzembe helyezésével valósítható meg. Ha azonban olyan kritikus erőforrásállapotok vannak, mint például a konfigurációs térképek, a feladatok és a potenciálisan titkos kulcsok, amelyeket valamilyen okból nem lehet rögzíteni a rendszerindítási folyamat során, fontolja meg a helyreállítási stratégiát. Általában ajánlott állapot nélküli számítási feladatokat futtatni a Kubernetesben, de ha az architektúra lemezalapú állapotot tartalmaz, akkor a tartalom helyreállítási stratégiáját is figyelembe kell vennie.

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 lesz felelős a fürterőforrás-állapotnak az Ön által választott célhelyre való leküldéséért és az Azure Disk-alapú állandó kötet pillanatképeinek koordinálásáért.

A VMware Velero egy olyan gyakori Kubernetes biztonsági mentési megoldás példája, amelyet közvetlenül telepíthet és kezelhet. Alternatív megoldásként az AKS biztonsági mentési bővítménye használható felügyelt Velero-implementáció biztosítására is. 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 az architektúrában a felügyelethez, monitorozáshoz, fizetéshez és biztonsághoz; például egy Azure Storage-fiók, az Azure Backup-tároló > konfigurációja és a Megbízható hozzáférés. A GitOps az állapot nélküli számítási feladatok futtatásának szándékával kombinálva a implementált helyreállítási megoldás.

Válasszon és érvényesítsen egy olyan 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 (RPO) & helyreállítási idő célkitűzését (RTO). Definiálja ezt 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 használható, de ez a szint nem kínál pénzügyileg támogatott SLA-t. Az SLA beszerzéséhez a Standard szintet kell választania. Javasoljuk, hogy minden éles fürt használja a Standard szintet. Ingyenes szintű fürtök lefoglalása éles üzem előtti fürtökhöz. Az Azure Rendelkezésre állási zónákkal kombinálva a Kubernetes API-kiszolgáló SLA-ja 99,95%-ra nő. A csomópontkészletek és más erőforrások a saját SLA-juk alá tartoznak.

Ü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 az Azure Container Registry georeplikálása, prémium termékváltozatokban érhetők el, ami drágább. A költség is nőni fog, mert a forgalom zónák és régiók közötti áthelyezésekor alkalmazott sávszélesség-díjak.

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 megbízhatóság biztosítása kényszerített feladatátvételi teszteléssel szimulált kimaradásokkal, például csomópont leállítása, egy adott zónában lévő összes AKS-erőforrás leállítása zonális hiba szimulálásához, vagy külső függőségi hiba meghívása. Az Azure Chaos Studio különböző típusú kimaradások szimulálására is használható az Azure-ban és a fürtön.

További információ: Azure Chaos Studio.

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

Az Azure Monitor Container Insights az ajánlott eszköz a tárolóterhelések teljesítményének monitorozására, mivel 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 processzorkihasználtságról az erőforrások és számítási feladatok állapotának figyelése érdekében. A podok méretezése során a teljesítmény monitorozására is használható. Ez magában foglalja az összegyűjtött adatok monitorozásához, elemzéséhez és vizualizációihoz kritikus fontosságú telemetriai adatok gyűjtését a trendek azonosításához, valamint a riasztások konfigurálását, hogy proaktív módon értesüljenek a kritikus problémákról.

A podokban üzemeltetett számítási feladatok többsége Prometheus-metrikákat bocsát ki. A Container Insights képes integrálni a Prometheussal a csomópontokból és a Kubernetesből gyűjtött alkalmazás- és számítási feladatok metrikáinak megtekintéséhez.

Vannak olyan külső megoldások, amelyek integrálhatók a Kubernetes szolgáltatással, például a Datadog, a Grafana vagy a New Relic használatával, ha a szervezet már használja őket.

Az AKS használatával az Azure felügyel néhány alapvető Kubernetes-szolgáltatást, és az AKS vezérlősík-összetevőinek naplói erőforrásnaplókként vannak implementálva az Azure-ban. Javasoljuk, hogy a legtöbb fürtön mindig engedélyezve legyen a következő, mivel segíthetnek a fürtproblémák elhárításában, és viszonylag alacsony naplósűrűséggel rendelkeznek:

• A ClusterAutoscaler naplózása a skálázási műveletek megfigyelhetővé viteléhez. További információ: A fürt automatikus skálázási naplóinak és állapotának lekérése.
• KubeControllerManager , hogy megfigyelhető legyen a Kubernetes és az Azure vezérlősík közötti interakció.
• A KubeAudit Rendszergazda hogy megfigyelhető legyen a fürtöt módosító tevékenységekben. Nincs ok arra, hogy mind a KubeAudit, mind a KubeAudit Rendszergazda mindkettő engedélyezve legyen, mivel a KubeAudit a KubeAudit szuperhalmaza Rendszergazda amely nem módosító (olvasási) műveleteket is tartalmaz.
• A Guard rögzíti a Microsoft Entra-azonosítót és az Azure RBAC-auditokat.

Más naplókategóriák, például a KubeScheduler vagy a KubeAudit, nagyon hasznosak lehetnek a fürt vagy a számítási feladatok életciklusának korai fejlesztése során, ahol a fürt automatikus skálázása, a podok elhelyezése és ütemezése és hasonló adatok segíthetnek a fürt- vagy számítási feladatok üzemeltetési problémáinak elhárításában. A kiterjesztett hibaelhárítási naplók teljes munkaidőben történő megtartása, miután a hibaelhárítási igények véget érnek, szükségtelen költségnek minősülhet az Azure Monitorban való betöltés és tárolás.

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 kódtára lehetővé teszi az AKS-fürtök állapotának és teljesítményének további megfigyelhetőségét, és támogatja a szolgáltatásiszint-célkitűzéseket (SLO-kat).

Az AKS monitorozási ajánlott eljárásairól az Azure Kubernetes Service (AKS) monitorozása az Azure Monitorral című témakörben olvashat bővebben.

Az AKS referenciaarchitektúráján található Windows-tárolókban található Windows-specifikus figyelési szempontok áttekintéséhez tekintse át a társcikket.

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

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

AKS-fürtfrissítések

Az üzleti követelményeknek megfelelő frissítési stratégia meghatározása rendkívül fontos. Az AKS-fürt verziójának vagy csomópontjainak frissítési dátumához és időpontjához tartozó kiszámíthatóság szintjének megértése, valamint az AKS-fürt frissítési tervét meghatározó alapvető szempontok az adott rendszerkép vagy bináris fájlok telepítésének kívánt mértéke. A kiszámíthatóság két fő AKS-fürtfrissítési tulajdonsághoz van kötve, amelyek a frissítési ütem és a karbantartási időszak. A beállítás azt határozza meg, hogy a frissítések manuálisan vagy automatikusan vannak-e telepítve. A szigorú biztonsági szabályozás alá nem tartozó AKS-fürtökkel rendelkező szervezetek heti vagy akár havi frissítéseket is fontolóra vehetnek, míg a többinek a biztonsági címkével ellátott javításokat kell frissítenie, amint elérhető (naponta). Az AKS-fürtöket nem módosítható infrastruktúraként üzemeltető szervezetek nem frissítik őket. Ez azt jelenti, hogy sem automatikus, sem manuális frissítés nem történik. Ehelyett, amikor egy kívánt frissítés elérhetővé válik, a replikabélyeg üzembe lesz helyezve, és csak akkor, ha az új infrastruktúrapéldány készen áll, a régi le lesz ürítve, így a legmagasabb szintű vezérlést biztosítja számukra.

Az AKS-fürt frissítési tervének meghatározása után könnyen megfeleltethető az AKS-csomópontok és az AKS-fürtverzió elérhető frissítési beállításainak:

• AKS-csomópontok:

  1. Nincs/Manuális frissítés: Ez nem módosítható infrastruktúrára, vagy ha a manuális frissítések a preferencia. Ez nagyobb szintű kiszámíthatóságot és vezérlést biztosít az AKS-csomópontok frissítéseinek felett.
  2. Automatikus felügyelet nélküli frissítések: Az AKS natív operációsrendszer-frissítéseket hajt végre. Ez kiszámíthatóságot biztosít azáltal, hogy konfigurálja a karbantartási időszakokat, és igazodik az üzlet szempontjából hasznoshoz. Ez a csúcsidőn és a legjobb üzemeltetésen alapulhat. A vezérlés szintje alacsony, mivel előre nem lehet tudni, hogy mi lesz kifejezetten telepítve az AKS-csomóponton belül.
  3. Automatikus csomópontrendszerkép-frissítések: Javasoljuk, hogy automatikusan frissítse az AKS-csomópont lemezképeit, amikor új virtuális merevlemezek (VHD-k) válnak elérhetővé. Tervezzen karbantartási ablakokat, hogy a lehető legnagyobb mértékben igazodjanak az üzleti igényekhez. A biztonsági címkével ellátott VHD-frissítések esetében ajánlott napi karbantartási időszakokat konfigurálni, amely a legalacsonyabb kiszámíthatóságot biztosítja. A rendszeres VHD-frissítések heti karbantartási időszakkal konfigurálhatók, kéthetente vagy akár havonta is. Attól függően, hogy szükség van-e biztonsági címkével ellátott és normál virtuális merevlemezekre az ütemezett karbantartási időszakkal kombinálva, a kiszámíthatóság ingadozik, és többé-kevésbé rugalmasan igazodik az üzleti követelményekhez. Bár ez mindig az üzleti követelményeknek megfelelő lenne, a valóság arra kötelezi a szervezeteket, hogy megtalálják a fordulópontot. A vezérlés szintje alacsony, mivel nem lehet előre tudni, hogy milyen bináris fájlok voltak belefoglalva egy új VHD-be, és mégis ez az automatikus frissítési típus ajánlott, mivel a rendszerképeket a rendszer ellenőrzi, mielőtt elérhetővé válik.

  Feljegyzés

  Az automatikus AKS-csomópontfrissítések konfigurálásával kapcsolatos további információkért tekintse meg a csomópont operációsrendszer-lemezképeinek automatikus frissítését.

• AKS-fürt verziója:

  1. Nincs/Manuális frissítés: Ez nem módosítható infrastruktúrára, vagy ha a manuális frissítések a preferencia. Ez nagyobb szintű kiszámíthatóságot és szabályozást biztosít az AKS-fürt verziófrissítései felett. Ezt javasoljuk, mivel ez teljes kontroll alatt marad, és lehetővé teszi egy új AKS-fürtverzió (azaz 1.14.x-től 1.15.x-es verzióig) tesztelését alacsonyabb környezetekben, mielőtt éles környezetben érne el.
  2. Automatikus frissítések: Az éles fürtöket nem ajánlott automatikusan javítani vagy frissíteni bármilyen módon (pl. 1.16.x-1.16.y) az új AKS-fürtverzióra, amely alacsonyabb környezetekben való megfelelő tesztelés nélkül érhető el. Bár a Kubernetes felsőbb rétegbeli kiadásai és az AKS-fürt verziófrissítései rendszeres ütemezéssel vannak összehangolva, a javaslat továbbra is védve kell lennie az éles AKS-fürtökkel, ami növeli a frissítési folyamat kiszámíthatóságát és ellenőrzését. Figyelembe véve ezt a konfigurációt az alacsonyabb környezetek esetében az operatív kiválóság részeként, lehetővé téve a proaktív rutinszerű tesztelési végrehajtásokat, hogy a lehető leghamarabb észleljék a lehetséges problémákat.

Tartsa naprakészen a Kubernetes-verziót a támogatott N-2 verziókkal. A Kubernetes legújabb verziójára való frissítés kritikus fontosságú, mert az új verziók gyakran jelennek meg.

További információ: A Kubernetes legújabb verziójának rendszeres frissítése és Azure Kubernetes Service-fürt frissítése.

A fürt által kiváltott eseményekről, például a fürt új AKS-verzió rendelkezésre állásáról szóló értesítés az Azure Event Grid AKS rendszertémakörén keresztül érhető el. A referencia-implementáció üzembe helyezi ezt az Event Grid rendszertémakört, hogy feliratkozzon az eseményre az Microsoft.ContainerService.NewKubernetesVersionAvailable eseménystream értesítési megoldásából.

Heti frissítések

Az AKS új csomópontrendszerképeket biztosít, amelyek rendelkeznek a legújabb operációs rendszerrel és futtatókörnyezeti frissítésekkel. Ezek az új képek nem lesznek automatikusan alkalmazva. Ön dönti el, hogy milyen gyakran frissüljenek a képek. Javasoljuk, hogy hetente frissítse a csomópontkészletek alaprendszerképét. További információ: Az Azure Kubernetes Service (AKS) csomópontjának rendszerképének frissítése az AKS kibocsátási megjegyzéseiben.

Napi frissítések

A rendszerkép-frissítések között az AKS-csomópontok egyenként töltik le és telepítik az operációs rendszert és a futtatókörnyezeti javításokat. A telepítéshez szükség lehet a csomópont virtuális gépeinek újraindítására. Az AKS a függőben lévő frissítések miatt nem indítja újra a csomópontokat. Legyen egy folyamat, amely figyeli a csomópontokat azokat az alkalmazott frissítéseket, amelyek újraindítást igényelnek, és szabályozott módon hajtja végre ezeknek a csomópontoknak az újraindítását. Egy nyílt forráskódú lehetőség a Kured (Kubernetes újraindítási démon).

Ha a csomópont lemezképeit a legújabb heti kiadással szinkronban tartja, a fokozott biztonsági helyzet fenntartása mellett minimálisra csökkenti ezeket az alkalmi újraindítási kéréseket. Ha csak csomópontrendszerkép-frissítésekre támaszkodik, az AKS kompatibilitását és a heti biztonsági javításokat biztosítja. Míg a napi frissítések alkalmazása gyorsabban oldja meg a biztonsági problémákat, nem feltétlenül tesztelték őket az AKS-ben. Ahol lehetséges, használja a csomópontrendszerkép frissítését elsődleges heti biztonsági javítási stratégiaként.

Biztonsági felügyelet

A tárolóinfrastruktúra figyelése aktív fenyegetések és potenciális biztonsági kockázatok esetén:

• Engedélyezze a Microsoft Defender for Containers számára a tárolólemezképek Felhőhöz készült Defender javaslatainak azonosítását és szervizeléséhez.
• A Microsoft Defender for Containers rendszeresen ellenőrzi a tárolólemezképeket a biztonsági rések keresése érdekében.
• A Microsoft Defender for Containers valós idejű biztonsági riasztásokat is létrehoz a gyanús tevékenységekhez.
• Az AKS virtuálisgép-gazdagépekre alkalmazott biztonsági megkeményedéssel kapcsolatos információkért tekintse meg a gazdagép operációs rendszerének biztonsági megkeményítését ismertető témakört.

Fürt- és számítási feladatok (DevOps)

Íme néhány szempont. További információkért lásd az Operatív kiválóság pillért.

Fürt rendszerindítása

A kiépítés befejezése után van egy működő fürtje, de a számítási feladatok üzembe helyezése előtt még szükség lehet lépésekre. A fürt előkészítésének folyamatát bootstrappingnek nevezzük, és olyan műveletekből állhat, mint az előfeltételként szolgáló rendszerképek fürtcsomópontokra való üzembe helyezése, névterek létrehozása és bármi más, amely megfelel a használati eset vagy szervezet követelményeinek.

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, hogy milyen lesz az egyedi rendszerindítási folyamatuk, és előre elő kell készíteniük a releváns objektumokat. Ha például fontos, hogy a Kured minden csomóponton fusson az alkalmazás számítási feladatainak üzembe helyezése előtt, a fürt operátora gondoskodni szeretne arról, hogy a cél Kured rendszerképet tartalmazó ACR már létezik a fürt kiépítése előtt .

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

• Önkonfiguráció a Flux vagy az Argo CD használatával
• Pipelines
• GitOps Flux v2 fürtbővítmény

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 fel a környezetet, és támogatja a rendszerindítás erőforrássablonokként való felvételét is az IaC-stratégiához való igazodáshoz.

Végül a bővítmény kubectl használatakor nincs szükség a rendszerindítási folyamat egyik részére sem, és a -based hozzáférés használata kubectlfenntartható vészhelyzeti törésjavítási helyzetekre. 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 minden normál konfigurációs tevékenység elvégezhető anélkül, hogy használatba kellene vennie kubectl.

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 lenne. Virtuális hálózatok kiépítése ezeken a hálózatokon belül a küllős és alhálózatokhoz. A 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. Az Azure Firewall egy alhálózata a központban.

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

Infrastruktúra használata kódként (IaC)

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. Az egyik lehetőség egy Azure Resource Manager- (ARM-) sablon. A másik a Terraform.

Győződjön meg arról, hogy az erőforrásokat a szabályozási szabályzatok szerint építi ki. Ha például a megfelelő virtuálisgép-méreteket választja ki, maradjon a költségkorlátokon belül, a rendelkezésre állási zóna beállításaival, hogy megfeleljenek az alkalmazás követelményeinek.

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. Az Azure CLI Windows és Linux rendszeren is támogatott. 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.

Szkripteket és sablonfájlokat tárol és verziószámokat tárol a forrásvezérlő rendszerben.

Számítási feladat CI/CD

A munkafolyamatokhoz és az üzembe helyezéshez szükséges folyamatoknak képesnek kell lenniük alkalmazások folyamatos létrehozására és üzembe helyezésére. Frissítések biztonságosan és gyorsan üzembe kell helyezni, és problémák esetén vissza kell állítani.

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

Ebben az architektúrában a GitHub Actionst választottuk a munkafolyamat és az üzembe helyezés kezeléséhez. Más népszerű lehetőségek közé tartozik az Azure DevOps Services é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 a verzió ellenőrzé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 rendszerindítása. Ennek érdekében hasznos a GitOps-megközelítés, amely 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 hogy a konfiguráció automatikusan megjelenjen a fürtben.

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.
• Frissítések a kívánt futó konfigurációt a módosítások alapján.

A módosítások üzembe helyezését szabályozó szabályzatokat is beállíthat.

Az alábbi példa bemutatja, hogyan automatizálhatja a fürtkonfigurációt a GitOps és a fluxus 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. A rendszer ezután leküldi a módosításokat egy git-kiszolgálóra.

2. A Flux 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ők nem rendelkeznek közvetlen hozzáféréssel a Kubernetes API-hoz a kubectlen keresztül.

5. Ágszabályzatok használata a Git-kiszolgálón. Így több fejlesztő is jóváhagyhat egy módosítást egy lekéréses kérelemben, mielőtt az éles környezetben alkalmazva lenne.

Bár a GitOps és a Flux manuálisan konfigurálható, az AKS-hez ajánlott a Flux v2-fürtbővítménnyel rendelkező GitOps.

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

Bármilyen módosítás (architektúraösszetevők, számítási feladat, fürtkonfiguráció) üzembe helyezése legalább egy éles üzem előtti AKS-fürtön. Ezzel szimulálni fogja a módosítással kapcsolatos problémákat, mielőtt üzembe helyezné az éles környezetben.

Minden fázisban futtathat teszteket/érvényesítéseket, mielőtt továbblépne a következőre, 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. Ennek az üzembe helyezésnek az éleshez hasonló mintát kell követnie, ugyanazzal a GitHub Actions-folyamattal vagy Flux-operátorokkal.

Az olyan fejlett üzembehelyezési technikák, mint a kék-zöld üzembe helyezés, az A/B-tesztelés és a Canary-kiadások, további folyamatokat és potenciálisan eszközhasználatot 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ülhető az architektúrában használt szolgáltatások költségei. Egyéb ajánlott eljárásokat a Microsoft Azure Well-Architected Framework Költségoptimalizálás szakaszában ismertetünk.

Fontolja meg az AKS költségelemzésének engedélyezését a fürtinfrastruktúra részletes költségfelosztásához a Kubernetes-specifikus szerkezetek szerint.

Az AKS alapkonfigurációs architektúráján található Windows-tárolókban található Windows-alapú számítási feladatokra vonatkozó költségkezelési szempontok áttekintéséhez tekintse át a kísérő cikket.

Üzembe helyezés

• A Kubernetes-fürt üzembe helyezésével, felügyeletével és üzemeltetésével kapcsolatban az AKS nem jár költségekkel. Mi befolyásolja a költségeket a fürt által felhasznált virtuálisgép-példányok, tárolási, naplóadatok és hálózati erőforrások. Érdemes lehet olcsóbb virtuális gépeket választani a rendszercsomópont-készletekhez. A DS2_v2 termékváltozat 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.

• Éles számítási feladatokhoz adjon hozzá egy üzemidős SLA-t. A fejlesztési/tesztelési vagy kísérleti számítási feladatokhoz tervezett fürtök esetében azonban vannak olyan megtakarítások, amelyek esetében nem szükséges garantálni a rendelkezésre állást. 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 éles számítási feladatok esetében é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.

• Ahelyett, hogy túlméretezett fürttel kezdené a skálázási igényeket, hozzon létre egy fürtöt minimális számú csomóponttal, és engedélyezze a fürt automatikus skálázását a méretezési döntések figyeléséhez és meghozatalához.

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

• A fürt diagnosztikáinak engedélyezése növelheti a költségeket.

• Ha a számítási feladat várhatóan hosszú ideig létezik, a csomópontköltségek csökkentése érdekében kötelezheti el magát egy vagy három évre fenntartott virtuálisgép-példányokra. További információ: Fenntartott virtuális gépek.

• Csomópontkészletek létrehozásakor használjon címkéket. A címkék hasznosak az egyéni jelentések létrehozásához a felmerülő költségek nyomon követéséhez. A címkék lehetővé teszik a költségek teljes számának nyomon követését és a költségek egy adott erőforrásra vagy csapatra való leképezését. 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.

• A régió rendelkezésre állási zónái közötti adatátvitel nem ingyenes. Ha a számítási feladat többrégiós, vagy a rendelkezésre állási zónák közötti átvitelek vannak, akkor további sávszélesség-költségekre számíthat. További információ: Forgalom a számlázási zónák és régiók között.

• Költségvetéseket hozhat létre, hogy a szervezet által meghatározott költségkorlátokon belül maradjon. Ennek egyik módja a költségvetések létrehozása az Azure Cost Management használatával. 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 költségeinek és a számítási költségeknek a monitorozása érdekében gyűjtsön költségadatokat a tárolásról, a sávszélességről, a tűzfalról és a naplókról. Az Azure különböző irányítópultokat biztosít a költségek monitorozásához és elemzéséhez:

• Azure Advisor

• Azure Cost Management

Ideális esetben valós időben vagy legalább rendszeres ütemezéssel monitorozza a költségeket a hónap vége előtt, amikor a költségek már ki vannak számítva. Emellett monitorozza a havi trendet, hogy a költségvetésben maradjon.

Az adatvezérelt döntések meghozatalához meg kell határozni, hogy melyik erőforrás (részletes szint) jár a legtöbb költséggel. Emellett jól ismeri az egyes erőforrások használatának kiszámításához használt mérőeszközöket is. A metrikák elemzésével meghatározhatja, hogy a platform például 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észlet kihasználatlan csomópontjait.

• 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. Továbbá, ha a fürtben nincsenek ütemezetten futtatandó számítási feladatok, fontolja meg az AKS Start/Stop funkció használatát az összes számítás leállításához, amely magában foglalja a rendszercsomópont-ké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

Folytassa az AKS alaparchitektúrájának megismerését:

• A mikroszolgáltatások AKS-alapkonfiguráción való üzemeltetéséről további információt az Advanced Azure Kubernetes Service (AKS) mikroszolgáltatás-architektúrában talál.
• Az AKS-alapkonfiguráció több régióban való üzembe helyezéséhez tekintse meg a többrégiós fürtök AKS-alapkonfigurációit.
• Az AKS alapkonfiguráció PCI-DSS 3.2.1-környezetbe való üzembe helyezéséhez lásd a PCI-DSS 3.2.1 AKS által szabályozott fürtöt.
• A Windows-tárolók referenciaarchitektúrához való hozzáadásának szempontjairól a következő társcikkben olvashat: Windows-tárolók az AKS alapkonfigurációs architektúráján

További információ az AKS-ről

• Tekintse át az AKS-termék ütemtervét, lásd az Azure Kubernetes Szolgáltatás ütemtervét a GitHubon.
• Ha frissítésre van szüksége a Kubernetesen, végezze el a Kubernetes-bevezetést , és fejlessze ki és telepítse az alkalmazásokat a Kubernetes képzési terveiben.

Kapcsolódó erőforrások

Tekintse meg a következő kapcsolódó útmutatókat:

• Azure Well-Architected Framework review for Azure Kubernetes Service (AKS)
• Az AKS célzónagyorsító, amely egy nagyvállalati szintű implementáció, amely ezen architektúrán alapul. A gyorsító segítségével konzisztens és megismételhető módon állíthatja be az Azure-környezetet az Azure Kubernetes Service (AKS) üzembe helyezéséhez használt Infrastruktúrakód (IaC) használatával.
• Az Azure Kubernetes Services (AKS) 2. napi üzemeltetési útmutatója

Tekintse meg a következő kapcsolódó architektúrákat:

• Mikroszolgáltatás-architektúra az Azure Kubernetes Service-ben
• Az Azure Firewall használata az Azure Kubernetes Service-fürt (AKS) védelméhez
• GitOps for Azure Kubernetes Service
• Adatstreamelés az AKS-sel