Alaparchitektúra egy Azure Kubernetes Service (AKS)-fürthöz

Azure Application Gateway

Azure Container Registry

Azure Firewall

Azure Kubernetes Service (AKS)

Azure-beli szerepköralapú hozzáférés-vezérlés

Ez a cikk egy ajánlott alapinfrastruktúra-architektúrát biztosít egy Azure Kubernetes Service (AKS)-fürt üzembe helyezéséhez. Követi a tervezési alapelveinket, és összhangban van az AKS építészeti legjobb gyakorlataival az Azure Well-Architected Keretrendszerből. A cikk több különböző interdiszciplináris csoportot vezet, például a hálózati, biztonsági és identitáskezelési csapatokat, amikor üzembe helyezik ezt az általános célú infrastruktúrát.

Ez az architektúra nem a számítási feladatokra összpontosít. Az AKS-fürtre összpontosít. Ez az információ a legtöbb AKS-fürt esetében a minimálisan ajánlott kiindulási pont. Olyan Azure szolgáltatásokkal integrálható, 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 eltérőek lehetnek az alkalmazáskörnyezetekben. Tekintsük az architektúrát az előgyártási és gyártási fázisok kiindulópontjának.

A Kubernetes egy olyan széles körű ökoszisztéma, amely túlmutat Azure és Microsoft technológiákon. Az AKS-fürtök üzembe helyezésekor ön a felelős a fürt tervezésével és működtetésével kapcsolatos számos döntésért. Az AKS-fürtök futtatása különböző gyártók zárt forráskódú összetevőit foglalja magában, beleértve a Microsoft, valamint a Kubernetes-ökoszisztéma nyílt forráskódú összetevőit. A tájkép gyakran változik, ezért rendszeresen ellenőrizze a döntéseket. A Kubernetes bevezetésekor elismeri, hogy a számítási feladatnak szüksége van a képességeire, és hogy a számítási feladatokért felelős csapat készen áll arra, hogy folyamatosan beruházzon.

Ennek az architektúrának az implementációját használhatja a GitHub: AKS alapkonfiguráció-implementáció alternatív kiindulási pontként, és konfigurálhatja az igényeinek megfelelően.

Note

A referenciaarchitektúra használatához ismerni kell a Kubernetes-t és annak fogalmait. Ha ismétlésre van szüksége, tekintse meg a Bevezetés a Kubernetesbe és Alkalmazások fejlesztése és üzembe helyezése a Kubernetes-en képzési útvonalakat.

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

Klaszter számítás

Az alapfürt kiszámítása
Konténerkép-referencia
Szabályzatkezelés

Identitáskezelés

Integrálja a Microsoft Entra ID-t a fürthöz
Integrate Microsoft Entra ID a számítási feladathoz

Biztonságos adatáramlás

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

Üzletmenet-folytonosság

Csomópontok és podok méretezhetősége
Üzletmenet-folytonossági döntések
Elérhetőségi zónákTöbb régió

Operations

Fürt- és terheléskezelés műveletei
Naplók és metrikák monitorozása és gyűjtése
Költségkezelés

Architecture

Az ábrán két csatlakoztatott virtuális hálózat látható. A központi virtuális hálózat tartalmazza az Azure Firewall-t, az Azure Bastion-t, és egy átjáróalhálózatot, amely a helyszíni rendszerhez kapcsolódik. A spoke virtuális hálózat több alhálózatot, az AKS-fürtöt és a csomópontkészleteket tartalmaz. A virtuális hálózatok egymáshoz kapcsolódása kétirányú kapcsolaton keresztül köti össze az agy és küllő virtuális hálózatokat. A nyilak a Key Vault és a Tárolóregisztrációs adatbázisból Private Link végpontok alhálózatára mutatnak. Az Azure Bastion alhálózatból (felügyelet) a küllő virtuális hálózat belső terheléselosztóhoz mutat egy nyíl. Egy nyíl a helyszíni hálózatról a helyszíni átjáróra mutat. Egy kétirányú nyíl, amelyen a virtuális hálózati társviszony felirat látható, a központi virtuális hálózattól a távoli irodai hálózat küllőjéig mutat. Egy nyíl az internetről a Azure Application Gateway alhálózatra mutat. Egy nyílpont alkotja az AKS-fürtöt a Azure Monitor munkaterület szakaszhoz, amely metrikákat és felügyelt Prometheust tartalmaz.

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

További információ: Hub küllős hálózati topológia Azure.

Hálózati topológia

Ez az architektúra küllős hálózati topológiát használ. Helyezze üzembe a központot és a küllőket különálló virtuális hálózatokban, amelyek virtuális hálózat-kapcsolat révén csatlakoznak. Ez a topológia számos előnnyel rendelkezik:

• Szegregált felügyelet engedélyezése. Alkalmazhatja a szabályozást, és betarthatja a minimális jogosultság (PoLP) elvét. Az Azure landing zóna fogalmát is támogatja a feladatok elkülönítésével.

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

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

• Használjon egy web application firewall szolgáltatást, amely segít az összes webalkalmazás HTTP-forgalomának vizsgálatában.

• 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 vállalati szintű telepítési zónához.

Központi virtuális hálózat

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

• Azure Firewall olyan globális tűzfalszabályzatokkal, amelyeket a központi informatikai csapatok a szervezeti szintű szabályok kikényszerítéséhez határoznak meg

• Azure Bastion, amely biztonságos alagutat hoz létre a magánhálózat határfelületén, ezáltal lehetővé teszi a klaszterkezelési műveletek végrehajtását.

• Átjáróalhálózat VPN-kapcsolathoz

• 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.

Az Azure Firewall-t fogadó alhálózat

Azure Firewall egy felügyelt tűzfalszolgáltatás. A Azure Firewall-példány biztosítja a kimenő hálózati forgalmat. A biztonsági réteg nélkül a forgalom egy rosszindulatú, nem Microsoft szolgáltatással kommunikálhat, amely bizalmas számítási feladatok adatait képes kiszűrni. A Azure Firewall Manager használatával központilag üzembe helyezhet és konfigurálhat több Azure Firewall-példányt, és kezelheti a Azure Firewall szabályzatokat ehhez a hub virtuális hálózathoz 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.

Az Azure Bastion-t fogadó alhálózat

Ez az alhálózat Azure Bastion használatos. Az Azure Bastion használatával biztonságosan hozzáférhet Azure erőforrásokhoz anélkül, hogy az erőforrásokat az internetre tárja. Ez az infrastruktúra az Azure Bastion-t használja az AKS-fürt API-kiszolgálójához való biztonságos csatlakozáshoz, a felügyeleti műveletek végrehajtásához. Az alhálózat csak felügyeletre és műveletekre használható.

Virtuális küllő hálózat

A spoke-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 Application Gateway kiszolgálására szolgáló alhálózat

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 Azure Web Application Firewall. Web Application Firewall biztonságossá teheti 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ése 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. A Azure belső terheléselosztók ebben az alhálózatban találhatók. További információ: A belső load balancer AKS.

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.

Alhálózat Azure Private Link végpontok üzemeltetéséhez

Hozzon létre Azure Private Link kapcsolatokat Azure Container Registry és Azure Key Vault számára, hogy a felhasználók a küllős virtuális hálózaton private végponton keresztül érhessék el ezeket a szolgáltatásokat. 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ózatban. Az alapkonfigurációban a végpontok a küllős virtual network belül egy dedikált alhálózatra lesznek üzembe helyezve. Ez a megközelítés csökkenti a társhálózati hálózati kapcsolaton áthaladó forgalmat. A fürthöz tartozó erőforrásokat ugyanabban a virtuális hálózatban tartja. Az alhálózat szintjén részletes biztonsági szabályokat is alkalmazhat hálózati biztonsági csoportok (NSG-k) használatával.

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

Az AKS API-kiszolgáló alhálózata

Konfigurálhat egy AKS-fürtöt úgy, hogy az API-kiszolgáló virtuális hálózati integrációját használja, amely a fürt API-kiszolgáló végpontját a virtuális hálózatában lévő delegált alhálózatba vetíti. Ezt a konfigurációt privát fürtnek nevezzük, mert biztosítja, hogy az API-kiszolgáló, a csomópontkészletek és a csatlakoztatott ügyfelek közötti összes forgalom teljes egészében a magánhálózaton belül maradjon.

Az AKS által felügyelt Kubernetes API-kiszolgáló és az ügyfelek (mind a fürt belső, mind a külső ügyfelek) közötti kommunikáció egy megbízható hálózatra korlátozódik.

Privát fürt esetén az NSG-k és más beépített hálózati vezérlők használatával biztosíthatja a környezet védelmét. Ez a konfiguráció tiltja az internet és a környezet közötti jogosulatlan nyilvános hozzáférést. További információ: Hozzon létre egy privát AKS-fürtöt.

IP-címek tervezése

Az ábrán egy egyszerű küllős AKS hálózati topológia látható. A központ Azure Firewall, Azure Bastion és átjáróval rendelkezik. A küllő alhálózatokkal rendelkezik a Application Gateway, a bejövő forgalom, a csomópontok, az API-kiszolgáló és a privát végpontok számára. A nyilak az internetről az Application Gateway-ra, majd a belső terheléselosztóra, a bejövő forgalomvezérlőre és a számítási feladatokat végző podokra irányuló forgalmat jelenítik meg. A kimenő nyilak a fürtből az Azure Firewallhoz mennek. A privát végpontok nyilai az Azure szolgáltatásokhoz mennek, például a Konténerregiszterhez és a Kulcstárhoz.

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

Ez a referenciaarchitektúra több hálózati megközelítést használ, amelyek mindegyike IP-címteret igényel:

• A Azure virtuális hálózat, amelyet olyan erőforrásokhoz használ, mint a fürtcsomópontok, a fürt API-kiszolgálója, a Azure-szolgáltatások privát végpontjai és az Application Gateway.

• A fürt Azure Container Networking Interface (CNI) átfedést használ, amely az IP-címeket külön címtérből a Azure virtuális hálózatba foglalja le.

Virtuális hálózati IP-címtér

A Azure 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 entitások IP-címeit. A Azure virtuális hálózat IP-címeinek tervezésekor vegye figyelembe a következő szempontokat:

• Frissítések: Az AKS rendszeresen frissíti a csomópontokat, hogy a mögöttes virtuális gépek up-to-date állapotban legyenek a biztonsági funkciók és más rendszerjavítások esetében. 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ópont egy IP-címet kap a fürt alhálózatától. Győződjön meg arról, hogy elegendő címtér áll rendelkezésre az ideiglenes csomópont IP-címeihez.

  Ebben az architektúrában a podok ip-címeket foglalnak le a Azure CNI overlay pod címteréből, beleértve a működés közbeni frissítéseket is. Ez a megközelítés csökkenti a Azure virtuális hálózatban használt IP-címek teljes számát a többi Kubernetes-hálózatkezelési megközelítéshez képest.

• Skálázhatóság: Vegye figyelembe a rendszer- és felhasználói csomópontok teljes számát, valamint azok maximális méretezhetőségi korlátait. Ha például 400%-kal szeretné felskálázni a rendszert, az összes felskálázott csomópont számára négyszeresére van szükség címekből.

  Mivel ez az architektúra Azure CNI-átfedést használ, a podok méretezhetősége nem befolyásolja a virtuális hálózat címterét.

• Private Link címek: Vegyük figyelembe a más Azure szolgáltatásokkal való kommunikációhoz szükséges címeket a Private Link-en keresztül. Ez az architektúra két címet jelöl ki a tárolóregisztráció és a Key Vault linkjeihez.

• Private fürt API-kiszolgáló címei: Az API-kiszolgáló virtuális hálózat integrációja segít vetít az AKS API-kiszolgálót végpontként a virtuális hálózaton belül. Ehhez a funkcióhoz minimum alhálózatméretre van szükség, ezért a hálózattervezés során győződjön meg arról, hogy megfelel ezeknek az előfeltételeknek.

• Megőrzött IP-címek: Azure a -specifikus címeket használja. 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. Ez az elkülönítés több kisebb méretű alhálózatot eredményez. A bejövő erőforrás is összetettebb lehet. Ennek eredményeképpen előfordulhat, hogy több bejövő vezérlőre van szükség, amelyek mindegyike további IP-címeket igényel.

Pod IP-címterülete

Azure CNI Overlay egy dedikált címtér használatával rendeli hozzá az IP-címeket a podokhoz, amely eltér a virtuális hálózaton használt címtértől. Használjon olyan IP-címteret, amely nem fedi át a virtuális hálózatot vagy bármely peeringelt virtuális hálózatot. Ha azonban több AKS-fürtöt hoz létre, biztonságosan használhatja ugyanazt a podcímteret az egyes fürtökön.

Azure CNI Overlay minden csomópontnak egy /24 címteret rendel a podjaihoz. Fontos gondoskodni arról, hogy a podcímtér elég nagy legyen. Adjon meg annyi /24 blokkot, amennyi a fürt csomópontjainak számához szükséges. Ne felejtse el belefoglalni a frissítések vagy a vertikális felskálázási műveletek során létrehozott ideiglenes csomópontokat. Ha például /16 címteret használ az osztály nélküli tartományközi útválasztási (CIDR) tartományhoz, a fürt körülbelül legfeljebb 250 csomópontra nőhet.

Minden csomópont legfeljebb 250 podot támogat, és ez a korlát a frissítések során ideiglenesen létrehozott podokat is magában foglalja.

További információ: az IP-cím tervezésének útmutatója Azure CNI-átfedéshez.

Egyéb IP-címtérbeli szempontok

Az architektúra teljes hálózatkezelési szempontjait a AKS alaphálózati topológiája című témakörben talál. Az AKS-fürtök IP-címzésének megtervezéséről további információkért lásd: Configure Azure CNI networking in AKS.

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ú funkcióitól és az AKS-bővítményektől függ. Vegye figyelembe a következő különbségeket az előzetes verziójú funkciók és a bővítmények között:

• Az AKS-csapat az előzetes verziójú funkciókat kiküldöttnek és fejlődőnek ismerteti, mivel ezek a funkciók általában csak néhány hónapig maradnak ebben az állapotban, mielőtt az általánosan elérhető (GA) fázisba kerülnének.

• Az AKS add-ons é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.

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ékkel bírnak egy általános célú fürthöz. Mivel ezek a funkciók kikerülnek az előzetes verzióból, ennek megfelelően módosul az alaparchitektúra. 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, ami magában foglalja 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.

Konténerkép-referencia

A klaszter tartalmazhatja a számítási feladatot és számos más rendszerképet, például az ingress kontrollert. Előfordulhat, hogy a képek némelyike nyilvános regisztrációs adatbázisokban található. A rendszerképek fürtbe való beemelésekor vegye figyelembe a következő szempontokat:

• A fürt hitelesítése szükséges az image lekéréséhez.

• Ha nyilvános rendszerképet használ, importálja a rendszerképet egy konténer-regisztrációs tárolóba, amely megfelel a szolgáltatásiszint-célkitűzésnek (SLO). 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, üzemeltetési problémák léphetnek fel. Fontolja meg a privát tárolóregisztrációs adatbázis (például Azure Container Registry) nyilvános beállításjegyzék helyett való használatának alábbi előnyeit:

  • Letilthatja a képekhez való jogosulatlan hozzáférést.
  • Nincsenek a nyilvánosság számára elérhető függőségei.
  • A képek letöltési naplóihoz férhet hozzá, hogy nyomon kövesse a tevékenységeket, és osztályozza a kapcsolati problémákat.
  • 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 a Azure Policy keresztül kényszerítheti ki. Ebben a referencia-implementációban a fürt csak a fürttel együtt üzembe helyezett dedikált Azure Container Registry példányról tölti le a lemezképeket.

Az alapfürt számítási erőforrásainak konfigurálása

Az AKS-ben minden csomópontkészlet általában egy virtuális gép méretezési csoporthoz van leképezve. A csomópontok minden csomópontkészletben virtuális gépek (VM-ek).

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 D2dv5-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 rövid élettartamú lemeze 64 GB.

A felhasználói csomópontkészlet kapacitásának tervezésekor vegye figyelembe a következő javaslatokat:

• 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 monitorozá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ó: Sizes for VMs in Azure.

• Helyezzen üzembe legalább két csomópontot, hogy a számítási feladat egy magas rendelkezésre állási mintát kövessen 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 a D4dv5 termékváltozatot használja az éles számítási feladatokhoz.

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

• Állítsa be az egyes csomópontok maximális podjait a kapacitástervezés alapján. Ha megpróbál létrehozni egy kapacitás-alapkonfigurációt, 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-cím korlátozásai alapján.

Az operációs rendszer kiválasztása

A legtöbb AKS-fürt linuxos operációs rendszert használ a csomópontkészletekhez. Ebben a referencia-implementációban az Azure Linux-t használjuk, amely egy könnyű, edzett Linux-disztribúció, és kifejezetten Azure-hoz van hangolva. Választhat másik Linux-disztribúciót, például az Ubuntu-t, ha szeretné, vagy ha Azure Linux nem felel meg a követelményeknek. Ha másik operációs rendszert választ, győződjön meg arról, hogy az operációsrendszer-lemez mérete megfelelő a lemezképhez. Egyes disztribúciók több helyet igényelnek, mint a Linux Azure, ezért előfordulhat, hogy növelnie kell a lemez méretét az üzembe helyezési vagy futásidejű problémák elkerülése érdekében.

Ha a számítási feladat vegyes technológiákból áll, különböző operációs rendszereket használhat különböző csomópontkészletekben. Ha azonban nincs szüksége különböző operációs rendszerekre, javasoljuk, hogy az összes számítási feladatcsomópont-készlethez egyetlen operációs rendszert használjon a működési összetettség csökkentése érdekében.

A fürt Microsoft Entra ID integrálása

A fürtbe és a fürtből való hozzáférés biztosítása kritikus fontosságú. A fürt szemszögéből megismerheti a belső-külső és külső-belső forgalom közötti különbséget:

• Belülről kifelé történő hozzáférés: Fontolja meg az AKS hozzáférést Azure összetevőkhöz, például a hálózati infrastruktúrához, a Tárolóregisztrációhoz és a Key Vaulthoz. Csak azokat az erőforrásokat engedélyezze, amelyekhez a fürt hozzáférhet.

• Kívülről befelé irányuló hozzáférés: Adjon azonosítóknak hozzáférést 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 Azure Resource Manager.

AKS-hozzáférés Azure összetevőkhöz

Az AKS kezelése a Microsoft Entra ID-n keresztül kétféleképpen lehetséges az Azure-hoz való hozzáférés érdekében: szolgáltatási hitelesítő adatokkal vagy felügyelt identitásokkal az Azure erőforrások esetén.

A Azure AKS-hozzáférésének kezelésére szolgáló két módszer közül a felügyelt identitásokat javasoljuk. A szolgáltatási főfelhasználók esetében manuálisan vagy programozott módon kell kezelnie és forgatnia a titkos kulcsokat. Felügyelt identitásokkal a Microsoft Entra ID kezeli és végrehajtja a titkos kulcsok hitelesítését és időben történő cseréjét.

Javasoljuk, hogy engedélyezze és használja felügyelt identitásokat az AKS-ben hogy a fürt Microsoft Entra ID keresztül kommunikálhasson a külső Azure erőforrásokkal. Ha nem használja azonnal Microsoft Entra ID integrációt, később is hozzáadhatja.

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 Registryvel hitelesíti magá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 regiszter hitelesítő adatait, ami úgy történik, hogy hozzáférést ad AcrPull a fürt kubelet által kezelt identitásának a regiszterhez. Ha nem használ felügyelt identitást, ezeket az adatokat tárolhatja egy Kubernetes-titokban, és imagePullSecrets használhatja annak lekérdezésére. Ezt a megközelítést nem javasoljuk, mert biztonsági összetettségeket vezet be, beleértve a titkos kód előzetes ismeretének szükségességét és a DevOps-folyamatban való tárolását. Emellett működési többletterhelést is hozzáad, mert el kell forgatnia a titkos kulcsot.

Ebben az architektúrában a fürt olyan Azure erőforrásokhoz fér hozzá, amelyeket a Microsoft Entra ID biztosít, és a felügyelt identitásokat támogató műveleteket hajt végre. Rendeljen hozzá Azure szerepköralapú hozzáférés-vezérlést (Azure RBAC) és engedélyeket a fürt felügyelt identitásaihoz, a fürt által végzett műveletektől függően. A fürt hitelesíti magát a Microsoft Entra ID, majd a hozzá rendelt szerepkörök alapján engedélyezi vagy megtagadja a hozzáférést. Íme néhány példa a referencia-implementációból, ahol az Azure beépített szerepkörei vannak hozzárendelve a klaszterhez:

• A Network közreműködői szerepkör kezeli a fürt sugárirányú virtuális hálózatának vezérlésének lehetőségét. Ezzel a szerepkör-hozzárendeléssel az AKS-fürt rendszerhez hozzárendelt identitás együttműködhet a belső bejövőforgalom-vezérlő szolgáltatás dedikált alhálózatával és az AKS privát API-kiszolgálóval.

• A Private DNS zóna közreműködői szerepköre kezeli a fürt azon képességét, hogy a zónát közvetlenül a fürtöt üzemeltető küllős virtuális hálózathoz kapcsolja. A privát fürtök egy private DNS zóna használatával távol tartják a DNS-rekordokat a nyilvános internetről. Továbbra is lehet létrehozni privát AKS-fürtöt nyilvános DNS-címmel. Javasoljuk, hogy explicit módon tiltsa le ezt a funkciót azáltal, hogy enablePrivateClusterPublicFQDNfalse beállítja, így megakadályozva a vezérlősík magánhálózati IP-címének közzétételét. Fontolja meg a Azure Policy használatát a nyilvános DNS-rekordok nélküli privát fürtök használatának kényszerítéséhez.

• A Monitoring Metrikák Közzétevő szerepkör kezeli a fürt azon képességét, hogy metrikákat küldjön az Azure Monitorba.

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

Fürt hozzáférés

Microsoft Entra integráció 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 az ön identitását az Azure szerepkörök ellenében hitelesíti, amelyek engedélyezettek a fürt hitelesítő adatainak lekérésére. További információért tekintse meg a következőt: Elérhető klaszterszerepkörök engedélyei.

Az AKS támogatja a Kubernetes-hozzáférést a Microsoft Entra ID segítségével, amely az identitásszolgáltatóként van integrálva a natív Kubernetes RBAC-vel, vagy a natív Azure RBAC használatával a fürthozzáférés vezérlésére. A következő szakaszok mindkét megközelítést részletesen ismertetik.

A Kubernetes RBAC társítása a Microsoft Entra ID-vel

A Kubernetes a következő API-objektumokon keresztül támogatja az RBAC-t:

• Engedélykészlet, amelyet egy Role vagy ClusterRole objektummal fürt-szintű engedélyekhez definiálsz.

• Olyan hozzárendelések, amelyek felhasználókat és csoportokat rendelnek hozzá, akik jogosultsággal rendelkeznek a műveletek végrehajtására. Kötéseket definiáljon a RoleBinding vagy ClusterRoleBinding objektum használatával.

A Kubernetes rendelkezik néhány beépített szerepkörrel, mint például a fürt-rendszergazda, a szerkesztő és a megtekintő. Kösse ezeket a szerepköröket Microsoft Entra felhasználókhoz és csoportokhoz a vállalati címtár használatával a hozzáférés kezeléséhez. További információért lásd: Kubernetes RBAC használata 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 is belefoglalja a Microsoft Entra hozzáférési felülvizsgálatokba.

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

Javasoljuk, hogy Azure RBAC és Azure szerepkör-hozzárendelések használatával kényszerítse ki a fürt engedélyezési ellenőrzését. Ez az engedélyezési módszer integrálható Microsoft Entra hitelesítéssel. Szerepköröket különböző hatókörökhöz rendelhet, például a felügyeleti csoporthoz, az előfizetéshez vagy az erőforráscsoporthoz. A hatókör alá tartozó összes fürt ezután örökli a konzisztens szerepkör-hozzárendelés készletet tekintve, hogy kinek van engedélye a Kubernetes-fürt objektumainak elérésére.

Nem javasoljuk a Kubernetes-natív RBAC-nak a használatát a ClusterRoleBindings és a RoleBindings esetén.

További információ: Azure RBAC kubernetes-engedélyezéshez.

Helyi fiókok

Az AKS támogatja a natív Kubernetes felhasználói 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óján kívül történik, ami megnehezíti a központosított felhasználói hozzáférés-ellenőrzést és szabályozást. A fürthöz való hozzáférést mindig Microsoft Entra ID használatával kezelheti, és konfigurálhatja a fürtöt úgy, hogy explicit módon tiltsa meg a helyi fiókhoz való hozzáférést.

Ebben a referenciamegvalósításban a helyi klaszterfiókokhoz való hozzáférés kifejezetten tilos, amikor a rendszer üzembe helyezi a klasztert.

Microsoft Entra ID integrálása a számítási feladathoz

A teljes fürthöz Azure rendszer által hozzárendelt felügyelt identitáshoz hasonlóan 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 Microsoft Entra ID keresztül férhessen hozzá az erőforrásokhoz. Tegyük fel például, hogy a munkaterhelés az Azure Storage-ban tárolja a fájlokat. Amikor hozzá kell férnie ezekhez a fájlokhoz, a pod Azure felügyelt identitásként hitelesíti magát az erőforráson.

Ebben a referencia-implementációban az AKS-en a Microsoft Entra Workload 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. További információkért lásd: Számítási feladat identitásfederáció.

Hálózati modell kiválasztása

Az AKS a Container Networking Interface (CNI) beépülő modulokat két hálózati modellben biztosítja: átfedéses és lapos. Mindkét modell támogatja a hálózati szabályzatokat a fürtön belüli forgalom kezeléséhez.

Egy lapos hálózati pluginnal, mint például az Azure CNI Pod Subnet, minden pod kap egy IP-címet a virtuális hálózati alhálózatból. Az ugyanabban a hálózatban vagy társhálózatban lévő erőforrások közvetlenül az IP-címük alapján férhetnek hozzá a podokhoz hálózati címfordítás (NAT) nélkül. Használjon lapos hálózatkezelési modellt, ha a számítási feladathoz a podok közvetlenül a virtuális hálózatról irányíthatók.

Ez a referencia-implementáció Azure CNI Overlay-t használ, amely egy átfedéses hálózati beépülő modul. A virtuális hálózati IP-címeket csak csomópontokhoz rendeli, és pod IP-címeket rendel hozzá egy külön CIDR-tartományhoz. Mivel Azure CNI-átfedés sokkal kevesebb virtuális hálózati IP-címet használ fel, mint a sima modellek, a legtöbb üzembe helyezéshez javasoljuk.

A modellekről további információt az AKS CNI hálózatkezelési áttekintésében és az AKS hálózati kapcsolatának és biztonságának ajánlott eljárásaiban talál.

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

A Kubernetes ingress források kezelik a bejövő forgalom útválasztását és elosztását a klaszter számára. A bejövő erőforrásoknak két része van:

• Az AKS által kezelt belső load balancer: A load balancer egy privát statikus IP-címen keresztül teszi elérhetővé az ingress vezérlőt. Egyetlen kapcsolattartó pontként szolgál, amely bejövő folyamatokat fogad.

  Ez az architektúra Azure Load Balancer használ. 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 a Application Gateway, és a kommunikáció az átviteli réteg biztonságán (TLS) keresztül történik. A bejövő forgalom TLS-titkosításával kapcsolatos további információkért tekintse meg a bejövő forgalom folyamatának szakaszát.

• A bejövőforgalom-vezérlő: Ez a példa a Traefiket használja. A felhasználói csomópontkészletben fut a fürtön belül. A belső load balancer fogadja a forgalmat, 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. podAntiAffinity erre a célra használható.

• Korlátozza a podok ütemezését, hogy azok csak a felhasználói csomópontkészletre kerüljenek a(z) nodeSelectors használatával. 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 Gateway-től kap forgalmat.

• Konfigurálja a readinessProbe és livenessProbe beállításokat, amelyek a megadott időközönként figyelik a podok egészségi állapotát. 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ő access adott erőforrásokra való korlátozását és a végrehajtható műveletek korlátozásá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.

Note

Válasszon egy megfelelő bejövőforgalom-vezérlőt a követelmények, a számítási feladatok, a csapat készségkészlete és a technológiai lehetőségek támogatottsága alapján. A legfontosabb, hogy a bejövőforgalom-vezérlőnek meg kell felelnie az SLO elvárásainak.

A Traefik egy nyílt forráskódú lehetőség egy Kubernetes-fürthöz, és ebben az architektúrában szemléltető célból szerepel. Nem-Microsoft termékek integrációját jeleníti meg az Azure szolgáltatásokkal. Az implementáció bemutatja, hogyan integrálható például a Traefik a Microsoft Entra Workload ID-val és a kulcstartóval.

Használhatja a Application Gateway bejövőforgalom-vezérlőt is, amely jól integrálható az AKS-sel. Application Gateway a bejövőforgalom-vezérlői szerepkörön túli előnyöket is biztosít. Ez a fürt virtuális hálózati belépési pontja, és megfigyelheti a fürtbe érkező forgalmat. Használja Application Gateway, ha az alkalmazáshoz web application firewall szükséges. Lehetővé teszi a TLS leállítását is.

Router 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 a Application Gateway alhálózatbó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ő típusú forgalmat tartalmazza:

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

• Kimenő forgalom a fürtben lévő podból vagy csomópontból egy külső szolgáltatás felé.

• 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.

Az ábra három különböző forgalmi mintát mutat be az architektúrán belül. A központi hálózat Azure Firewall, Azure Bastion, átjáróval és Azure Monitor rendelkezik. A spoke hálózatban az AKS-fürt az Application Gateway található a belépési pontnál. A zöld nyilak az internetről érkező bejövő forgalmat az Application Gateway-en, a belső terheléselosztón, az ingress controlleren, és végül a számítási feladat podokon keresztül jelenítik meg. A narancssárga nyilak a podok közötti forgalmat jelenítik meg a fürtben. A piros nyilak a fürtről az Azure Firewall felé irányuló kimenő forgalmat jelenítik meg. A privát végpontok nyílbillentyűi a Tárolóregisztrációs adatbázisra és Key Vault mutatnak.

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 Application Gateway két különböző TLS-tanúsítvány használatával történik, ahogyan az alábbi ábrán látható.

Az ábrán végponttól végpontig terjedő TLS-forgalom látható, amely az ügyféltől a munkaterhelésig tart. Az ügyfél HTTPS-forgalmat küld a Application Gateway. A Key Vault és az Application Gateway közötti nyíl a tanúsítványlekérést jeleníti meg. Application Gateway leállítja a TLS-t, majd újra titkosítja a belső load balancer felé irányuló forgalmat (HTTPS). A Key Vault és az ingress controller közötti másik nyíl jelzi a tanúsítvány CSI-illesztőprogramon keresztüli lekérését. A belső load balancer továbbítja a titkosított forgalmat a bejövő forgalomvezérlőnek, amely leállítja a TLS-t. Az utolsó nyíl az HTTP-forgalmat jeleníti meg az ingress vezérlőtől a munkaterhelés podjaiig. Minden TLS-végpont meg van jelölve.

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 a 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ás-tűzfallal rendelkezik, és lefolytatja a TLS kézfogást a bicycle.contoso.com számára, így csak biztonságos titkosításokat engedélyez. Application Gateway egy TLS-végpont, amely azért fontos, mert Application Gateway web application firewall ellenőriznie kell a egyszerű szöveges kérést és választ. 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álható a Application Gateway. További információ: TLS-leállítás Key Vault tanúsítványokkal.

   Application Gateway feldolgozza web application firewall ellenőrzési szabályokat, és olyan útválasztási szabályokat futtat, amelyek továbbítják a forgalmat a konfigurált háttérrendszerbe.

3. Amikor a forgalom az Application Gateway-en keresztül a háttérrendszerbe kerül, újra titkosítja a rendszer egy másik TLS-tanúsítvánnyal, amely egy helyettesítő tanúsítvány a *.aks-ingress.contoso.com számára, mivel ez továbbítódik a belső load balancer felé. Ez az újrakezelés titkosítással biztosítja, hogy a nem biztonságos forgalom ne áramoljon a klaszter alhálózatába.

4. A bejövő forgalmat kezelő vezérlő a terheléselosztón keresztül fogadja a titkosított forgalmat. A vezérlő egy másik TLS-végpont a(z) *.aks-ingress.contoso.com számára, és HTTP-n keresztül továbbítja a forgalmat a számítási feladat podjaira. A tanúsítványok tárolása Key Vault történik, é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 Web Application Firewall védelemmel. Ez a megközelítés minimálisra csökkenti a többletterhelést a számítási feladatok felügyeletében és a gyenge hálózati teljesítményből adódó túlterhelést. A számítási feladatok és a megfelelőségi követelmények határozzák meg, hogy hol hajtja végre TLS-leállítást.

Kimenő forgalom folyamata

Ebben az architektúrában azt javasoljuk, hogy a fürtből érkező összes kimenő forgalom haladjon át az Azure Firewallon. Használhatja saját hasonló hálózati virtuális berendezését is. Nem ajánlunk más kimenő beállításokat, például Azure NAT Gateway vagy HTTP-proxyt mert nem biztosítanak hálózati forgalomvizsgálatot. Az Zero Trust vezérléshez és a forgalom vizsgálatának képességéhez küldje el az összes kimenő forgalmat Azure Firewall keresztül. Implementálja ezt a konfigurációt felhasználó által megadott útvonalakkal (UDR-ekkel). Az útvonal következő ugrása a Azure Firewall private IP-címe. Azure Firewall dönti el, hogy a meghatározott szabályok vagy a beépített fenyegetésfelderítési szabályok alapján blokkolja vagy engedélyezi-e a kimenő forgalmat.

A Azure Firewall másik lehetősége a AKS HTTP-proxy funkció használata. A fürtön kívülre irányuló összes forgalom a HTTP-proxy IP-címére kerül, amely azt továbbítja vagy eldobja.

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

Note

Ha nyilvános terheléselosztót használ nyilvános pontként a bejövő forgalomhoz és a kimenő forgalomhoz Azure Firewall UDR-ek használatával, aszimmetrikus útválasztási forgatókönyv jelenhet meg. Ez az architektúra belső terheléselosztókat használ a Application Gateway mögötti dedikált bejövő alhálózatban. Ez a kialakítási lehetőség növeli a biztonságot, és kiküszöböli az aszimmetrikus útválasztással kapcsolatos problémákat is. Vagy átirányíthatja a bejövő forgalmat a tűzfalon Application Gateway előtt vagy után, de ez a megközelítés a legtöbb esetben nem szükséges, és nem javasoljuk. Az aszimmetrikus útválasztásról további információt az Azure standard terheléselosztó integrálása a tűzfallal című témakörben talál.

A Zero Trust vezérlés kivétele az, amikor 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 konténer-regisztrációból, vagy bizalmas adatokat kell letöltenie a Key Vaultból. Ezekben a forgatókönyvekben a Private Link használatát javasoljuk.

A Private Link használatának 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 Link a célszolgáltatás nyilvános végponton való használata helyett további konfigurációra van szükség. Emellett nem minden Azure szolgáltatás vagy termék támogatja a Private Link. 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 Private Link 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 Azure Firewall szabályokon és a célszolgáltatásba beépített tűzfalon keresztül szabályozhatja a hozzáférést. Mivel ez a forgalom a tűzfal statikus IP-címén halad át, felveheti ezeket a címeket a szolgáltatás IP-engedélyezési listájába.

Az Azure-szolgáltatásokhoz nyilvános végpontokon keresztüli csatlakozás egyik hátránya, hogy Azure Firewall ezután több szabályra van szükség annak biztosításához, hogy csak egy adott alhálózatról érkező forgalmat engedélyezi. Vegye figyelembe ezeket a címeket, ha több IP-címet szeretne használni a kimenő forgalomhoz Azure Firewall. Ellenkező esetben elérheti a portok kimerülését. További információ a több IP-cím tervezéséről: Több IP-címmel rendelkező Azure Firewall létrehozása.

Pod–Pod forgalom

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

A fürt beállításakor engedélyezze a hálózati házirendet, mert később nem lehet hozzáadni. Az NetworkPolicy technológiák implementálására több lehetőség közül választhat. Javasoljuk, Azure hálózati házirendet, amelyhez Azure CNI szükséges. 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. A Calico-t nem fedi a standard Azure támogatás.

További információ: Differenciák Azure hálózati házirendmotorok 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 kezelési műveleteket szeretnének végrehajtani 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éseket. Ilyen erőforrások például a buildügynök-készlet egy DevOps-folyamatban, egy Azure Bastion példány a 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, javasoljuk, hogy állítson be egy privát AKS-fürtöt.

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

Javasoljuk, hogy az AKS-fürtöt privát fürtként telepítse. Minden vezérlősík- és csomópontkészlet-forgalom a magánhálózaton marad, és nem lesz elérhető a nyilvános interneten. Ez a referencia-implementáció úgy állít be egy privát fürtöt, hogy az API-kiszolgálót integrálja a virtuális hálózattal. Az alacsonyabb környezetek a kényelem érdekében megfontolhatják a privát fürtjavaslat enyhítését. Az éles AKS-fürtöket azonban mindig magánfürtként kell üzembe helyezni a biztonságos üzembe helyezési alapkonfiguráció érdekében.

A privát AKS-fürtökre jutó forgalom származhat a csatolt virtuális hálózatból, a társhálózatokból vagy a távoli hálózatok privát végpontjaiból. Bár az AKS-csomópontok természetesen a küllőn élnek, a felügyeleti feladatokat végző operátorok dedikált hálózati útvonalat igényelnek az AKS API-kiszolgáló privát eléréséhez. Ezt a kapcsolatot a következő módokon hozhatja létre:

• Tunnelling: Az Azure Bastion használatával nyisson alagutat közvetlenül a fürt API-kiszolgálójához.
• Jump-box: Jump-box virtuális gép kiépítése, és az Azure Bastion használatával SSH-n vagy RDP-n keresztüli csatlakozás. Innen az operátor kéréseket küld a fürt API-kiszolgálójára a privát IP-címén keresztül.

A referencia-implementációban Azure Bastion használunk az AKS API-kiszolgálóhoz való bújtatáshoz a fürtkezelési műveletek végrehajtásakor. Ez a megközelítés általában egyszerűbben kezelhető, kevésbé költséges, mint egy jump-box virtuális gép üzembe helyezése és kezelése, és kevésbé összetett a több operátor közötti koordinációhoz. Az alábbi követelmények bármelyike esetén azonban választhatja a jump-box virtuális gép használatát:

• Az operátorok nem biztonságos eszközöket használnak. A jump-box virtuális gépek erősebb biztonsági szigorítást biztosíthatnak, ha az ügyféleszközök nem megbízhatók.
• Az operátorok instabil hálózatokon keresztül csatlakoznak. A jump-box virtuális gépek stabilabb kapcsolatot biztosíthatnak a fürthöz, különösen a hosszú ideig futó vagy kötegkezelési műveletekhez.
• Az operátorok speciális diagnosztikai eszközöket használnak. Előfordulhat, hogy a diagnosztikai eszközök bizonyos típusai, például a csomagrögzítés nem működnek megfelelően a tunneling módszerekkel.

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

Titkos kulcsokat tárol egy felügyelt kulcstárolóban, például Key Vault. 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ési naplót biztosít. Emellett az alapvető titkos adatokat is elkerülíti az üzembehelyezési folyamatból. Ebben az architektúrában egy Key Vault tűzfal van engedélyezve és konfigurálva, és a Private Linket használják az Azure erőforrásokhoz való csatlakozásra, mint például a Key Vault számára a titkokhoz és tanúsítványokhoz való hozzáféréshez.

Key Vault jól integrálva van más Azure szolgáltatásokkal. A szolgáltatások beépített funkciójával hozzáférjen titkokhoz. Application Gateway bejövő forgalmi áramlathoz való TLS-tanúsítvány hozzáféréséről a Bejövő forgalmi áramlás részben talál bővebb információt.

A Key Vault Azure RBAC-engedélymodellje lehetővé teszi, hogy a munkafolyamatok identitásait a Key Vault Titkos információk felhasználója vagy a Key Vault Olvasó szerepköréhez rendeljék, és hozzáférjenek a titkokhoz. További információ: Access Key Vault Azure RBAC használatával.

Hozzáférés a fürt titkaihoz

A munkaterhelés identitásai használatával engedélyeznie kell, hogy egy pod hozzáférjen titkos adatokhoz egy adott tárolóból. A lekérési folyamat megkönnyítése érdekében használjon egy titoktá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 Vault titkos kulcstár CSI-illesztőprogramjával használja. A bővítmény lekéri a TLS-tanúsítványt a Key Vaultból, és betölti az illesztőprogramot abba a podba, amely a bejövő forgalmat vezérlő rendszert futtatja. 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.

Terhelés tárolás

Az architektúra számítási feladatai állapot nélküliek. Ha állapotot kell tárolnia, azt javasoljuk, hogy a fürtön kívül tárolja. 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 alkalmazások számára az AKS-ben.

Szabályzatkezelés

Az AKS-fürt kezelésének hatékony módja az irányítás szabályzatok általi érvényesítése. A Kubernetes az Open Policy Agent (OPA) Gatekeeper használatával implementálja a szabályzatokat. Az AKS-hez az Azure Policy-n keresztül 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ályérvényesítését, és naplózza az összes szabályzat-ellenőrzést. A politikai módosítások nem jelennek meg azonnal a clusterben, így késésekre lehet számítani.

Az AKS-fürtök kezeléséhez többféleképpen is használhatja az Azure Policyt:

• 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 az Azure Policy for Kubernetes segítségével.

Egy gyakori példa arra, hogy egy szabályzat hasznos lehet, a konténer képek szabályozása és érvényesítése körül található. A konténerképek biztonsági rések forrása lehetnek, és egyes szervezetek megkövetelik, hogy a nem megbízható konténerképek egy konténerkép-ellenőrző eszközzel legyenek érvényesítve, majd jóváhagyva, mielőtt gyártási klaszterben használhatók lennének. Ezt a folyamatot a Azure Policy használatával kényszerítheti ki, és letilthatja a nem megbízható tárolólemezképek fürtre való üzembe helyezését. További információ: Kvarantin minta.

Szabályzatok megadásakor alkalmazza őket a munkaterhelés követelményei alapján. Vegye figyelembe az alábbi tényezőket:

• Döntse el, hogy beállítja-e a szabályzatok gyűjteményét, más néven kezdeményezéseket, vagy egyéni szabályzatokat választ. Azure Policy két beépített kezdeményezést biztosít: alapszintű és korlátozott. Minden kezdeményezés az AKS-fürtre 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 az erőforrásokhoz, például a Container Registry, az Application Gateway vagy a Key Vault, amelyek együttműködnek a fürttel. A szervezet követelményei alapján válasszon szabályzatokat.

• Döntse el, hogy ellenőrizni vagy megtagadni kívánja 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. Legyen óvatos, amikor a Megtagadás módot választja, mert az túl korlátozó lehet ahhoz, hogy a számítási feladat működjön.

• Döntse el, hogy vannak-e olyan területek a számítási feladatban, amelyeknek nem kellene a tervezésnek megfelelőnek lenniük. Azure Policy megadhatja azokat a Kubernetes-névtereket, amelyek mentesülnek a szabályzatkényszerítés alól. Javasoljuk, hogy továbbra is alkalmazza a szabályzatokat ellenőrzési módban, hogy tisztában legyen ezekkel az esetekkel.

• Döntse el, hogy vannak-e 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ó: A szabályzatok egyéni definícióinak létrehozása és hozzárendelése.

• Döntse el, hogy rendelkezik-e szervezeti szintű követelményekkel. Ha igen, vegye fel ezeket a szabályzatokat a felügyeleti csoport szintjén. A fürtnek saját feladatspecifikus szabályzatokat kellene megállapítania, még akkor is, ha a szervezet rendelkezik általános szabályzatokkal.

• Döntse el, hogy Azure szabályzatokat kell-e hozzárendelnie adott hatókörökhöz. Győződjön meg arról, hogy a gyártási szabályzatokat a tesztkörnyezet-tel is ellenőrzik. Ellenkező esetben az éles környezetben történő üzembe helyezés során váratlan további korlátozásokba ütközhet, amelyekről nem számolt be az előkészítés során.

Ez a referencia-implementáció lehetővé teszi az Azure Policy használatát az AKS-fürt létrehozásakor. A korlátozó kezdeményezés ellenőrzési módban van hozzárendelve, hogy betekintést nyerjen a nem megfelelőség láthatósága érdekében.

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 képfájlok csak az üzembe helyezett tárolóregisztrációs példányból legyenek letöltve.

Fontolja meg saját egyéni kezdeményezések létrehozását. Egyesítse a munkaterhelésre vonatkozó szabályzatokat egyetlen kiosztásban.

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

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

A növekvő igényeknek megfelelően a Kubernetes azáltal tud kibővülni, hogy több podot ad hozzá a meglévő csomópontokhoz a podok horizontális automatikus skálázása révén. 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 az egyik módszer az, hogy értesítést kapunk, ha hibát jelez a Kubernetes ütemezője. Egy másik módja annak, hogy idővel figyelemmel kísérje a függőben lévő podokat. A csomópontok számát a Azure CLI vagy a Azure portálon módosíthatja.

Javasoljuk, hogy az automatikus skálázási módszert használja, mert a manuális mechanizmusok némelyike beépített az automatikus skálázóba.

Á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.

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, hogy állítsa be a replikák minimális és maximális számá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álatot biztosítjuk natív módon. 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 versenyállapot, például amikor a HPA ellenőrzi, hogy a skálázási művelet befejeződik-e. Az eredmény tehát helytelen arányszámítás lehet. További információ: A skálázási események lehűlési ideje.

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 feladatokat hajtja, ahelyett, hogy a számítási feladat processzorhoz kötött vagy memóriaalapú lenne. 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 a 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 skálázója

A cluster automatikus skálázó 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 beállítása során. Minden felhasználói csomópontkészlethez külön automatikus skálázó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 beállít egy új csomópontot a csomópontkészletben. Ezzel szemben a fürtskálázó ellenőrzi a csomópontok kihasználatlan 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 hatásaitó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.

Ü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ó: Megjelenítések a megbízhatósági célok meghatározásához. Tekintse át az AKS szolgáltatásiszint-szerződésének (SLA) feltételeit a legújabb online szolgáltatások SLÁ-jában szereplő cikkben.

Klaszter csomó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 vagy kapacitásra van szüksége, méretezze felfelé a további csomópontok hozzáadásával.

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észletet a CriticalAddonsOnly taint fertőzött, hogy az alkalmazás podjai ne legyenek ütemezve a rendszercsomópont-készletekben.

A fürt rendszeres fenntartású feladatai, 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

• Pod erőforrás-követelmények megadása: Javasoljuk, hogy adja meg a pod erőforrás-követelményeket a telepítésekben. 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 felfrissítési esemény során. További információ: Pod-megszakítási költségvetés.

  Konfiguráljon több replikát az üzemelő példányban a hardverhibákhoz hasonló fennakadások kezelésére. A tervezett események, például frissítések és fejlesztések esetén a kiesési költségvetés segíthet biztosítani a szükséges pod-replikák számát a várt alkalmazásterhelés 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 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ás-kvóták.

  Note

  Ha a fürt szintjén állít be erőforráskvótákat, problémák léphetnek fel, ha olyan külső számítási feladatokat helyez üzembe, amelyek nem rendelkeznek megfelelő kérésekkel és korlátozásokkal. Ha névtérszinten állít be kvótákat, az biztosítja, hogy azok csak a számítási feladatok összetevőire vonatkozzanak.

• Podkérelmek és korlátok beállítása: Állítsa be a kéréseket és korlátokat, hogy a Kubernetes hatékonyan lefoglalhassa a processzor- és memóriaerőforrásokat a podokhoz. Nagyobb tárolósűrűséget biztosít egy csomóponton. 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 állapítja azt a küszöbértéket, amely instabilitást okoz a fürtben.

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

elérhetőségi zónák

Bizonyos típusú kimaradások elleni védelemhez használja a availability zones, ha a régió támogatja őket. A vezérlősík összetevői és a csomópontkészletek csomópontjai is zónaredundánsak, ami azt jelenti, hogy több zónában vannak elosztva. 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-skálázási csoportra van leképezve, amely kezeli a csomópont példányait és a skálázhatóságot. 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:

• Entire infrastruktúra: Válasszon egy régiót, amely támogatja az elérhetőségi zónákat. További információ: Limitations. Az üzemidős SLA használatához ki kell választania a Standard vagy a Premium szintet. Az üzemidőszolgáltatási szint (SLA) nagyobb, ha elérhetőségi zónákat használ.

• Cluster: Csak akkor állíthat be elérhetőségi zónákat, ha létrehozza a csomópontkészletet. 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 virtuálisgép-méretezési csoport minden zónában azonos hardverkonfigurációt biztosít.

  A zónaredundancia 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 feltétlenül oszlanak el a rendelkezésre állási zónák között.

• Függő erőforrások: Az elérhetőségi zónák használatának rugalmassági előnyeinek kihasználása érdekében minden szolgáltatási függőségnek támogatnia kell a zónákat. 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.

  Tegyük fel például, hogy a számítási feladat olyan adatbázist használ, amely nem zónarugalmas. Ha hiba történik, előfordulhat, hogy az AKS-csomópont egy másik zónába kerül, de az adatbázis nem költözik a csomóponttal az adott zónába, így a számítási feladat megszakad.

Az architektúra egyszerűsége érdekében az AKS egyetlen régióban van üzembe helyezve, három rendelkezésre állási zónára kiterjedő csomópontkészletekkel. Az infrastruktúra egyéb erőforrásai, például a 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ó

Amikor engedélyezi az elérhetőségi zónákat, nem biztosított a megfelelő lefedettség abban a valószínűtlen esetben, ha az egész 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.

• párosított régiókat, 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. Azure gondoskodik arról, hogy egyszerre csak egy régió legyen frissítve a párban. A régiók nem rendelkeznek párokkal. 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 szállítási (CI/CD) folyamat használatát, amelyet úgy konfigurál, hogy egy régióhiba esetén vezényelje a helyreállítást. 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 folyamatos access biztosít a képek számára, 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 Balancer, mert el tudja osztani a nemwebalapú forgalmat a zónák között. Ha régiók közötti forgalmat szeretne elosztani, fontolja meg a Azure Front Door. Más lehetőségekért lásd: Válasszon egy terheléselosztót.

Note

A többrégiós fürtök AKS-alapkonfigurációja példaforgatókönyv kibővíti a cikkben szereplő architektúrát, hogy több régiót is belefoglaljon egy aktív-aktív és magas rendelkezésre állású konfigurációba.

Katasztrófa utáni helyreállítás

Ideális esetben, ha hiba történik az elsődleges régióban, gyorsan válthat egy másik régióban lévő példányra. Lehetséges, hogy előre létrehoz egy fürtöt, vagy megvárja a létrehozását addig, amíg szükség lesz rá. Vegye figyelembe a következőket:

• 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.

• Állítson be minden Azure szolgáltatást 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áját kódként, beleértve az AKS-fürtöt és az összes többi 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.

Klaszter biztonsági mentése

Számos architektúra esetén beállíthat egy új fürtöt, amelyet a GitOps alapú fürtindítással visszaállíthat az üzemeltetési állapotba, majd telepítheti rá az alkalmazásokat. 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ése a helyreállítási stratégia részét kell, hogy képezze, telepítenie kell egy olyan megoldást, amely megfelel a vállalkozás fürtön belüli követelményeinek. Ez az ügynök felelős a fürterőforrás-állapotnak a választott célhelyre való leküldéséért, és Azure lemezalapú, állandó kötet pillanatképeinek koordinálásáért.

A VMware Velero egy olyan gyakori Kubernetes biztonsági mentési megoldás, amelyet közvetlenül telepíthet és kezelhet. Vagy használhatja a AKS biztonsági mentési bővítményt a felügyelt Velero-implementáció biztosításához. Az AKS biztonsági mentési bővítmény támogatja a Kubernetes-erőforrások és az állandó kötetek biztonsági mentését, az ütemezéseket és a biztonsági mentési hatóköröket pedig tárolási konfigurációként kezelik az Azure Backupban.

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, a monitorozáshoz, a vásárláshoz és a biztonsághoz. Ezek az erőforrások tartalmazhatnak egy Azure Storage fiókot, egy Azure Backup-tárolót és -konfigurációt, valamint a megbízható hozzáférési funkciót. Ehelyett a GitOps és az állapot nélküli számítási feladatok futtatásának szándéka 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, amely magában foglalja 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 szerver SLA

Az AKS ingyenes szolgáltatásként is használható, de ez a szint nem nyújt pénzügyileg támogatott SLA-t. Az SLA beszerzéséhez ki kell választania a Standard szintet. Javasoljuk, hogy minden gyártási klaszter a Standard szintet használja. Foglalja le az ingyenes szintet a tesztelési fürtökhöz, és a Prémium szintet csak a küldetéskritikus számítási feladatokhoz. Ha Azure rendelkezésre állási zónákat használ, 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 SLA online services című témakörben talál további információt.

Kompromisszum

Az architektúra zónákban és különösen régiókban történő üzembe helyezéséhez költség és rendelkezésre állás közötti kompromisszumot jelent. Egyes replikációs funkciók, például a tárolóregisztrációs adatbázisban lévő georeplikálás, prémium termékváltozatokban érhetők el, ami drágább. Többrégiós telepítések esetén a költségek is növekednek, mivel a sávszélesség díjai éppen akkor érvényesek, amikor a forgalom a régiók között mozog.

Emellett a zónák közötti csomópontkommunikációban kis mértékű többlet hálózati késésre, a régiók közötti kommunikációban pedig nagyobb késésre számíthat. 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 foglalhatnak 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 zónahiba szimulálásához, vagy külső függőségi hiba meghívását. Az Azure Chaos Studio az Azure-ban és a fürtön előforduló különböző típusú kimaradások szimulálására is használható.

További információ: Chaos Studio.

Naplók és metrikák monitorozása és gyűjtése

Javasoljuk a Azure Monitor Kubernetes monitorozási szolgáltatásait a tárolóterhelések teljesítményének monitorozásához, mert valós időben tekintheti meg az eseményeket. Azure Monitor rögzíti a tárolónaplókat a futó podokró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 podok méretezése során a Azure Monitor 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.

Naplógyűjtés engedélyezése podokból

A ContainerLogV2 naplóséma úgy lett kialakítva, hogy a Kubernetes-podokból származó tárolónaplókat egyszerűbben rögzítse. A naplóbejegyzések egy Azure Log Analytics munkaterület ContainerLogV2 táblájába vannak összesítve.

Az AKS-fürtökben két elsődleges módszer van a podnapló-gyűjtemény konfigurálására. Mindkét módszer lehetővé teszi a beállítások testreszabását. Szűrheti a névtereket, módosíthatja a gyűjtési időközöket, engedélyezheti vagy letilthatja bizonyos funkciókat (például ContainerLogV2 vagy ContainerLogV2-HighScale), és megadhatja, hogy mely adatfolyamokat kell összegyűjteni.

• Ha több fürt központi, újrafelhasználható monitorozási konfigurációit szeretné használni, vagy a fürtkonfigurációt Azure natív erőforrásokban szeretné külsővé tenni, használja a adatgyűjtési szabályokat (DCRs). A DCR-ek olyan Azure erőforrások, amelyeket az Azure Resource Manager vezérlősíkja natív módon kezel, és Bicep fájlokba is felvehetők. A referencia-implementáció DCR-eket használ.

• A monitorozást alternatívaként ConfigMaps használatával is definiálhatja, amelyek nem bizalmas Kubernetes YAML-objektumok, és amelyek a Kubernetes API vezérlősíkján keresztül vannak konfigurálva. A fürtön futó Azure Monitor ügynök figyeli a ConfigMap-objektumokat. Előre definiált beállításokat használ annak meghatározásához, hogy mely adatokat gyűjtse össze.

Ha mindkét módszer engedélyezve van, a ConfigMap-beállítások elsőbbséget élveznek a DCR-ekkel szemben. Kerülje a tárolónapló-gyűjtés ConfigMap- és DCR-konfigurációjának keveredését, mert ez nehezen elhárítható naplózási problémákhoz vezethet.

Riasztások és Prometheus-metrikák

A kimaradások és a hibás működés jelentős kockázatokat jelentenek a számítási feladatok alkalmazásai számára, ezért elengedhetetlen az infrastruktúra állapotával és teljesítményével kapcsolatos problémák proaktív azonosítása. Amikor figyeli a környezetet, és a tanultak alapján cselekszik, csökkentheti a fennakadásokat, és javíthatja a megoldás megbízhatóságát. A fürt lehetséges meghibásodási feltételeinek előrejelzéséhez engedélyezze a a Kubernetes javasolt Prometheus riasztási szabályait.

A podokban üzemeltetett számítási feladatok többsége Prometheus-metrikákat bocsát ki. Azure Monitor integrálhatók a Prometheussal. Megtekintheti a tárolókból, podokból, csomópontokból és a fürtbő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. Így ha szervezete már használja ezeket a megoldásokat, kihasználhatja azokat.

Azure infrastruktúra és Kubernetes vezérlő sík naplói

Az AKS-sel Azure kezeli az alapvető Kubernetes-szolgáltatásokat. Azure alkalmazza az AKS vezérlősík-összetevőinek naplóit erőforrás-naplók formájában. Ezek 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. Javasoljuk, hogy a legtöbb fürtön engedélyezze a következő beállításokat:

• ClusterAutoscaler: A naplózás segítségével betekintést nyerhetünk a skálázási műveletekbe. További információért lásd: A fürt automatikus skálázási naplói és állapota.

• KubeControllerManager: Megfigyelheti a Kubernetes és a Azure vezérlősík közötti interakciót.

• kube-audit-admin: Megfigyelheti a fürtöt módosító tevékenységeket. Nincs szükség mind a kube-audit, mind a kube-audit-admin engedélyezésére, mivel a kube-audit egy szuperhalmaz, amely a nem módosító (csak olvasási) műveleteket is magában foglal.

• guard: Microsoft Entra ID és Azure RBAC-auditok rögzítése.

Hasznos lehet engedélyezni más naplókategóriákat, mint például KubeScheduler vagy kube-audit, a klaszter vagy a számítási feladatok életciklusának korai fejlesztése során. A hozzáadott fürtök automatikus skálázása, a podok elhelyezése és ütemezése, valamint 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 folyamatosan tartja a hibaelhárítási igények befejeződése után, felesleges költségek merülhetnek fel az adatok betöltésére és tárolására az Azure Monitorba.

Azure Monitor tartalmaz egy sor meglévő napló lekérdezést, amelyekből kiindulhat, de 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 query csomag használatával mentheti és újra felhasználhatja a napló lekérdezéseit. Az egyedi lekérdezések könyvtára jobb rálátást nyújt az AKS-fürtök állapotára és teljesítményére. Támogatja az Ön SLO-inak elérését.

Az AKS ajánlott eljárásainak figyelésével kapcsolatos további információkért lásd: Monitor AKS és Azure Monitor.

Hálózati metrikák

Az alapszintű fürtszintű hálózati metrikák natív platform- és Prometheus-metrikákon keresztül érhetők el. Az AKS csomóponthálózati metrikák segítségével a hálózati metrikákat a csomópont szintjén is közzéteheti a Prometheus-metrikák használatával. A legtöbb fürtnek tartalmaznia kell a hálózati megfigyelhetőséget, hogy további hálózati hibaelhárítási képességeket biztosítson, és hogy észlelje a nem várt hálózati használatot vagy problémákat a csomópont szintjén.

A referencia-implementáció Azure Monitor használ, amely szintén gyűjt néhány hálózattal kapcsolatos metrikát. A referencia-implementáció tiltja egyes hálózati metrikák közvetlen gyűjtését az Azure Monitortól, és ehelyett a hálózati megfigyelhetőségi adatokat egy Azure Monitor munkaterületen managed Prometheus-t használva gyűjti össze.

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 ezeket a részletes metrikákat az Advanced Container Networking Services funkció használatával érheted el. A legtöbb számítási feladathoz nincs szükség ilyen mélységű hálózati megfigyelhetőségre. Ne engedélyezze a fejlett hálózati megfigyelhetőséget, hacsak a podok nem igényelnek nagymértékben optimalizált hálózatot, és nem követelik meg a csomagszintű érzékenységet.

Költségoptimalizálás naplózáshoz

A referencia-implementáció úgy konfigurálja a ContainerLogV2 táblát, hogy kiindulási pontként használja az Alaptervet. Microsoft Defender for Containers és a referencia-implementációhoz létrehozott riasztások nem használják fel ezt a táblázatot, így az Alapszintű csomag valószínűleg költséghatékony, mert csökkenti az adatbetöltési költségeket.

A naplók mennyiségének és lekérdezési követelményeinek fejlődésével válassza ki az igényeinek leginkább megfelelő táblázattervet. Ha a megoldás olvasásigényessé válik, ahol a lekérdezések gyakran ellenőrzik a táblaadatokat, az alapértelmezett Elemzési csomag megfelelőbb lehet. Az Analytics-csomag kiküszöböli a lekérdezési díjakat, ami olyan helyzetekre optimalizál, amikor a lekérdezési tevékenység meghaladja a betöltési költségeket. Ha figyeli a használati mintákat, és szükség szerint módosítja a táblázatterveket, egyensúlyt teremthet a monitorozási megoldás költségei és funkciói között.

További információ: Az Log Analytics munkaterület adathasználatán alapuló táblaterv kijelölése.

Ö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.

Note

Az AKS rendelkezik egy automatikus csomópontjavítási funkcióval amely beépített önjavítást biztosít az infrastruktúra-csomópontok számá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éteg kezelését kell elvégezni.

• A Kubernetes verziója (például a Kubernetes 1.32.3–1.32.7 vagy a Kubernetes 1.32.7–1.33.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 Windows Update vagy apt. Az operációs rendszer szállítója közvetlenül biztosítja ezeket a frissítéseket, és ezek nincsenek tesztelve a fürt Kubernetes-verziójával. 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 minden AKS-fürt, csomópontkészlet vagy csomópont milyen gyakran frissül (a frissítési ü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 ahogyan a fürtön futó számítási feladatnak biztonságos ügyintézési gyakorlatra van szüksége, a fürtök frissítése is igényli ezt.

A javítással és frissítéssel kapcsolatos átfogó perspektíváért tekintse meg a AKS javítással és frissítéssel kapcsolatos útmutatóját a AKS 2. napi ü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 változtathatatlan 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 kép frissítés értékét none, és a cluster automatikus frissítés értékét 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, a következő lépéseket kell végrehajtania:

1. Tesztelje a frissítést egy előkészületi környezetben, és értékelje annak kompatibilitását egy új fürtön.

2. Telepítsen egy éles replikabélyeget, amely tartalmazza a frissített AKS-verziót és a csomópontkészlet virtuális merevlemezeit.

3. Amikor az új termelési fürt készen áll, kiürítse a régi fürtöt, és végül szerelje le azt.

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

Helyszíni frissítések

Azok a számítási feladatok, amelyek nem változtathatatlan infrastruktúraként működtetik az AKS-fürtöket, rendszeresen frissíteniük kell a futó fürtöket mindhárom réteg frissítéséhez. 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ás 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 pod-megszakítási költségvetéseket, hogy az alkalmazás stabil maradjon a forgó frissítések alatt. 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 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 Azure kvótának és IP-címtérnek elérhetőnek kell lennie az új csomópontokhoz. A túlterhelési érték 33% 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. Emellett 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 futtathat 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. Microsoft teszteli a frissítéseket az AKS-verzión. Windows csomópontok esetében a frissítések havonta körülbelül egyszer történnek. Linux-csomópontok esetén a frissítések körülbelül hetente 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 a frissítések időben történő alkalmazását bármilyen csomópontképet használó operációs rendszer esetén.

• 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ő-verziószámait a AKS kiadáskövető használatával követheti nyomon.

Ha a fürt biztonsági követelményei szigorúbb javítási ütemtervet igényelnek, és a fürt meg tudja engedni magának a lehetséges megszakításokat, akkor használja inkább az SecurityPatch upgrade csatornát. 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 Microsoft fontosnak tart ahhoz, hogy a következő ütemezett csomópontrendszerkép-frissítés előtt megjelenjenek. A SecurityPatch csatorna használatakor a NodeImage csatorna által kapott frissítéseket is megkapja. A SecurityPatch csatorna opció továbbra is tiszteletben tartja a karbantartási időablakokat, ezért győződjön meg arról, hogy a karbantartási időablakban rendszeres szünetek vannak (például naponta vagy két naponta), hogy támogassa ezeket a váratlan biztonsági frissítéseket.

A legtöbb helyszíni frissítést használó fürtnek kerülnie kell a csomópont képfrissítési NoneUnmanaged csatornaopciókat.

A fürt helyben történő 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 naprakész maradj a Kubernetes-frissítésekkel kapcsolatban. A két legutóbbi verzióban (N-2) 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 megfelelő óvatossággal és alapossággal képesnek kell lennie a helyben történő AKS-verziófrissítések végrehajtására. A helyben történő AKS-verziófrissítések kockázatát többnyire csökkenteni lehet a megfelelő előzetes teszteléssel, a kvótaérvényesítéssel és a pod-kimaradási költségvetés beállításával. A helyszíni frissítések azonban váratlan viselkedést eredményezhetnek. Ha a helyben történő frissítések túl kockázatosnak minősülnek a számítási feladatokhoz, javasoljuk, hogy a fennmaradó javaslatok követése helyett az AKS-fürtök blue-green üzembe helyezési megközelítését használja.

Javasoljuk, hogy a Kubernetes-fürt első üzembe helyezésekor kerülje a fürt automatikus frissítése funkciót. Használjon kézi 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 bekerülnének az éles környezetbe. 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 egy 'naprakész' gondolkodásmódot követni, mint egy hosszú távú támogatás megközelítést.

Warning

Nem javasoljuk egy éles AKS-fürt automatikus javítását vagy frissítését, még alverziófrissítések esetén sem, hacsak először nem tesztelte ezeket a frissítéseket az alacsonyabb környezetekben. További információkért tekintse meg az alábbiakat: A Kubernetes legújabb verziójára történő frissítés és AKS-fürt frissítése.

Értesítést kaphat, ha új AKS-verzió érhető el a fürthöz az Azure Event Grid AKS rendszerének használatával. A referencia-implementáció üzembe helyezi ezt az Event Grid-rendszert, hogy előfizethesse a Microsoft.ContainerService.NewKubernetesVersionAvailable eseményre az eseménystream értesítési megoldásából. Tekintse át a AKS kibocsátási megjegyzéseit a kompatibilitási problémák, a viselkedésváltozások vagy a funkciók elavulása esetén.

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. Éles rendszerek esetében ritkán haladunk túl patch. Ha automatikusan frissíti az AKS-verziót, ellenőrizze az infrastruktúra AKS-verzióbeállítását kódként (IaC), hogy a kettő ne ússzon ki a szinkronizálásból. Konfigurálja a tervezett karbantartási időszakot az automatikus frissítési művelet támogatásához.

Biztonsági monitorozás

A tárolóinfrastruktúra figyelése az aktív fenyegetések és a potenciális biztonsági kockázatok szempontjából is. További információt a következő források tartalmaznak:

• Microsoft Defender for Containers azonosítja és orvosolja a Defender for Cloud tárolóképekre vonatkozó javaslatait.
• A tárolókhoz készült Defender rendszeresen vizsgálja a konténerképeket biztonsági rések után.
• Defender a tárolók esetében is létrehoz valós idejű biztonsági riasztásokat a gyanús tevékenységek esetén.
• Az AKS-ben lévő alkalmazások és fürtök biztonsági fogalmai részletes információk arról, hogy a tárolóbiztonság hogyan védi a teljes teljes folyamatot a buildeléstől az AKS-ben futó alkalmazásterhelésekig.

Klaszter- és számítási feladat operációk

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

Fürt rendszerindítása

A fürt beállítása után a rendszer már működőképes, de előfordulhat, hogy a számítási feladatok telepítése előtt további lépések végrehajtása szükséges lehet. Az előkészítési folyamatot, amellyel a fürtöt beállítjuk, bootstrappingnek nevezzük. A rendszerindítás gyakran magában foglalja az előfeltételként szolgáló rendszerképek fürtcsomópontokra való üzembe helyezését, névterek létrehozását és a szervezet használati helyzetének követelményeinek megfelelő egyéb feladatok elvégzését.

Az újonnan beállított fürtről egy megfelelően konfiguráltra való áttérés felgyorsításához meg kell határoznia az egyedi rendszerindítási folyamatot, és előre el kell készítenie a megfelelő objektumokat. Ha például olyan szolgáltatáshálót használ, mint a Linkerd vagy a Consul Connect, általában az alkalmazás számítási feladatainak ütemezése előtt helyezi üzembe a hálót. A fürt beállítása előtt ellenőriznie kell, hogy a szolgáltatásháló lemezképei egy korábban létrehozott tárolóregisztrációs adatbázisban találhatók-e. Ez az ellenőrzés segít megelőzni az üzembe helyezési késéseket vagy hibákat.

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

• GitOps Flux v2 klaszter kiterjesztés
• Pipelines
• Önkonfigurálás Flux vagy Argo CD-vel, például

Note

Ezen módszerek bármelyike bármilyen fürttopológiával működik, de javasoljuk a GitOps Flux v2 fürtbővítményt a flották számára az egységesség és a nagyobb léptékű könnyebb szabályozás miatt. Ha csak néhány klasztert futtat, a GitOps túl összetett lehet. Ehelyett úgy dönthet, hogy integrálja a folyamatot egy vagy több üzembe helyezési folyamatba, hogy biztosítsa a rendszerindítás megtörténtét. Használja a szervezet és a csapat célkitűzéseinek leginkább megfelelő módszert.

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 környezetet szilárd menedzsment alapokkal teremti meg a jövőben, és támogatja a bootstrapping erőforrássablonokként való alkalmazását is az IaC-stratégia összehangolása érdekében.

Végül, ha a GitOps Flux v2 fürtbővítményt használja, a kubectl nem szükséges a rendszerindítási folyamat egyik szakaszához sem. A kubectl-alapú hozzáférés lefoglalható vészhelyzeti 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 a kubectl használata nélkül is elvégezhet minden normál konfigurációs tevékenységet.

Munkafelelősségek 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. Állítson be virtuális hálózatokat a központhoz és küllőkhöz, valamint az alhálózatokhoz 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, a bejövő erőforrásokhoz és a privát AKS API-kiszolgálóhoz. Helyezzen üzembe egy alhálózatot Azure Firewall a központban.

Egy másik feladat az alapvető munkaterhelés integrálása a Microsoft Entra ID-vel.

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. A referencia-implementáció Bicep használ, de választhat a Terraform vagy Azure Resource Manager sablonok (ARM-sablonok) helyett.

Mindenképpen állítson be erőforrásokat a szabályozási szabályzatok szerint. 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. A Azure Policy használatával is kikényszerítheti a szervezet szabályzatait ezekre a döntésekre.

Ha parancssorozatot kell írnia, használja a Azure CLI. Ezek a parancsok számos Azure szolgáltatást fednek le, és szkriptekkel automatizálhatók. Windows és Linux támogatja a Azure CLI. Egy másik platformfüggetlen lehetőség a 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.

Munka-terhelés CI/CD

A munkafolyamatokhoz és üzembe helyezéshez használt folyamatoknak képeseknek kell lenniük az alkalmazások folyamatos létrehozására és üzembe helyezésére. A frissítéseknek biztonságosan és gyorsan kell üzembe helyezniük, és vissza kell tudniuk állni, 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 munkaterhelési konténerképek változtatásait automatikusan üzembe helyezheti a klaszterben.

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

Klaszter CI/CD

Diagram, amely a CI/CD számítási feladatot jeleníti meg.

Az ábrán a CI/CD munkafolyamat látható balról jobbra. A bal oldalon a kódként használt infrastruktúra ikon a forrásvezérlőben tárolt deklaratív konfigurációt jelöli. Egy vízszintes nyíl, "Deploy" felirattal, az infrastruktúra mint kód felől egy "GitOps" felirattal ellátott központi mezőre mutat. Ez a mező Azure Pipelines, GitHub Actions és Jenkins-folyamatokat tartalmaz. A GitOps-mezőből a Szinkronizálás feliratú nyíl egy AKS-ikonra mutat.

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 változá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 telepítésének megkezdése. A GitOps-megközelítés azért hasznos, mert lehetővé teszi, hogy az operátorok deklaratívan megadják a rendszerindítási folyamatot az IaC-stratégia részeként, és automatikusan lássák a konfiguráció visszatükröződését a klaszterben.

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ökprogram a Flux, amely a fürtben lévő egy vagy több operátort használja a Kubernetes környezetén belüli üzembe helyezések aktiválásához. A Flux a következő feladatokat végzi el:

• Az összes konfigurált adattár monitorozása
• Új konfigurációmódosításokat észlel
• Központi telepítések aktiválása
• Frissíti a kívánt futó konfigurációt a módosítások alapján

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

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

A diagram a GitOps-munkafolyamatot négy számozott lépéssel mutatja be balról jobbra. A bal szélen egy laptopot tartalmazó fejlesztői ikon jelenik meg 1. lépésként, ahol a felhasználó az IaC-módosításokat egy Git-adattárba küldi. A 2. lépés a Git-adattárat mutatja be, amely egy git clone --mirror címkével ellátott nyíllal csatlakozik a Flux-ikonhoz az AKS-fürt határán belül. A 3. lépésben egy kubectl feliratú nyíl látható, amely a fürtön belül a Flux ikonról a Kubernetes API-kiszolgáló ikonra mutat. A 4. lépés egy piros kört jelenít meg, amelynek átlós vonala van a fejlesztő és a Kubernetes API-kiszolgáló között egy keresztbe helyezett kubectl címkével.

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-nek írásvédett hozzáférése van a Git-adattárhoz, hogy meggyőződjön 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 access 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.

Terhelések és klaszterek üzembe helyezési stratégiái

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

A következő szakasz folytatása előtt minden fázisban 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 éles használathoz hasonló eljárást kell követnie ugyanazzal a GitHub Actions és Flux operátorok használatával.

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. 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 a Well-Architected Framework for AKS című cikkben ismertetett javaslatokat. Az általános számítási feladatokra vonatkozó javaslatokért tekintse meg a Design költségoptimalizálási ellenőrzőlistát.

Az alaparchitektúrában használt összetevők költségbecslését a Azure díjszabási kalkulátorban találja. Módosítsa a becslést úgy, hogy tartalmazza a használati esethez szükséges összetevőket.

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

Provision

• Ismerje meg, hogy honnan származnak a költségek. Minimális költségek társulnak az AKS-hez a Kubernetes-fürt üzembe helyezésével, kezelésével és üzemeltetésével kapcsolatban. A költségeket a fürt által felhasznált virtuális gép példányok, tárhely, naplóadatok és hálózati erőforrások befolyásolják. Érdemes lehet olcsóbb virtuális gépeket választani a rendszercsomópont-készletekhez. A Ddv5 sorozat a rendszercsomópontkészlet tipikus virtuálisgép-típusa, és a referencia-implementáció a Standard_D2d_v5 termékváltozatot használja.

• Ne használja ugyanazt a konfigurációt fejlesztői/tesztelési és éles környezetekhez. Az éles munkaterhelések extra követelményeket támasztanak a nagy rendelkezésre állás érdekében, és általában drágábbak. Ez a konfiguráció nem szükséges a fejlesztői/tesztelési környezetben.

• Adjon hozzá rendelkezésre állási SLA-t az éles környezetben futó feladatokhoz. Vannak azonban megtakarítások a fejlesztési és tesztelési vagy kísérleti munkaterhelésekhez tervezett fürtök esetében, ahol a rendelkezésre állás nem garantált. Az SLO például elegendő lehet. Emellett, ha a számítási feladat támogatja, fontolja meg a dedikált spot csomópontkészletek használatát, amelyek spot virtuális gépeket futtatnak.

  Nem gyártási feladatokhoz, amelyek részét képezi az AKS számítási feladatarchitektúra, valamint az Azure SQL Database vagy az Azure App Service, értékelje ki, hogy jogosult-e az Azure Dev/Test előfizetések használatára és a szolgáltatások kedvezményes igénybevételére.

• Hozzon létre egy fürtöt a csomópontok minimális számával, és kapcsolja be a fürt automatikus skálázóját, hogy monitorozhassa és méretezési döntéseket hozhasson, ahelyett, hogy a skálázási igények kielégítésére az elejétől túlméretezett fürttel indulna.

• Á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 a csomópontok teljes kapacitását használhassa.

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

• Kötelezze el magát egy vagy hároméves Azure fenntartott virtuálisgép-példányokra a csomópontköltségek csökkentése érdekében, ha a számítási feladatnak hosszú ideig kell léteznie. További információ: Költségmegtakarítás az Azure fenntartott virtuális gé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 meg van osztva a csapatok között, minden fogyasztó számára díjvisszatérítési jelentéseket kell készíteni a megosztott felhőszolgáltatások mért költségeinek azonosításához. További információért lásd: Állítsa be a tünetet, címkét vagy taget egy csomópontkészlethez.

• 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ó: Bandwidth díjszabás.

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

Monitor

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

• Azure Advisor
• Költségkezelés

Valós időben vagy rendszeres ütemezéssel figyelheti a költségeket, hogy a hónap vége előtt, amikor már ki vannak számítva a költségek, megtehesse a szükséges lépéseket. A havi trendek folyamatos figyelemmel kísérése érdekében maradjon a költségvetésen belül.

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ámokat Azure Monitor metrikákban tekintheti meg.

Optimize

Kövesse Azure Advisor javaslatait. Az optimalizálás egyéb módjai:

• 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.

  Important

  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ópontszámának) gyors vagy gyakori módosítása a költségek szabályozásához nem szándékos vagy kontraproduktív eredményekhez vezethet. 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 fölösleges idejének újraszámítása a fürt automatikus skálázási beállításainak frissítésekor történik.

• 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 jogosultsági szintűvé alakítását a teljesítménymetrikák időbeli elemzésével.

• Ha a számítási feladat támogatja, a felhasználói csomópontkészleteket nulla csomópontra skálázhatja ha nem várható, hogy futjanak. Ha a fürtben nem futnak ütemezett 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 információ: AKS díjszabás.

Következő lépések

• AKS ütemterve a GitHub

Kapcsolódó erőforrások

• Az AKS mikroszolgáltatás-architektúrája
• Microservices architektúra az AKS-en
• Használja az Azure Firewall szolgáltatást az AKS-fürt védelméhez
• GitOps for AKS
• Adatstreamelés az AKS

Ez a cikk egy ajánlott alapinfrastruktúra-architektúrát biztosít egy Azure Kubernetes Service (AKS)-fürt üzembe helyezéséhez. Követi a tervezési alapelveinket, és összhangban van az AKS építészeti legjobb gyakorlataival az Azure Well-Architected Keretrendszerből. A cikk több különböző interdiszciplináris csoportot vezet, például a hálózati, biztonsági és identitáskezelési csapatokat, amikor üzembe helyezik ezt az általános célú infrastruktúrát.

Ez az architektúra nem a számítási feladatokra összpontosít. Az AKS-fürtre összpontosít. Ez az információ a legtöbb AKS-fürt esetében a minimálisan ajánlott kiindulási pont. Olyan Azure szolgáltatásokkal integrálható, 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 eltérőek lehetnek az alkalmazáskörnyezetekben. Tekintsük az architektúrát az előgyártási és gyártási fázisok kiindulópontjának.

A Kubernetes egy olyan széles körű ökoszisztéma, amely túlmutat Azure és Microsoft technológiákon. Az AKS-fürtök üzembe helyezésekor ön a felelős a fürt tervezésével és működtetésével kapcsolatos számos döntésért. Az AKS-fürtök futtatása különböző gyártók zárt forráskódú összetevőit foglalja magában, beleértve a Microsoft, valamint a Kubernetes-ökoszisztéma nyílt forráskódú összetevőit. A tájkép gyakran változik, ezért rendszeresen ellenőrizze a döntéseket. A Kubernetes bevezetésekor elismeri, hogy a számítási feladatnak szüksége van a képességeire, és hogy a számítási feladatokért felelős csapat készen áll arra, hogy folyamatosan beruházzon.

Ennek az architektúrának az implementációját használhatja a GitHub: AKS alapkonfiguráció-implementáció alternatív kiindulási pontként, és konfigurálhatja az igényeinek megfelelően.

Note

A referenciaarchitektúra használatához ismerni kell a Kubernetes-t és annak fogalmait. Ha ismétlésre van szüksége, tekintse meg a Bevezetés a Kubernetesbe és Alkalmazások fejlesztése és üzembe helyezése a Kubernetes-en képzési útvonalakat.

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

Klaszter számítás

Az alapfürt kiszámítása
Konténerkép-referencia
Szabályzatkezelés

Identitáskezelés

Integrálja a Microsoft Entra ID-t a fürthöz
Integrate Microsoft Entra ID a számítási feladathoz

Biztonságos adatáramlás

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

Üzletmenet-folytonosság

Csomópontok és podok méretezhetősége
Üzletmenet-folytonossági döntések
Elérhetőségi zónákTöbb régió

Operations

Fürt- és terheléskezelés műveletei
Naplók és metrikák monitorozása és gyűjtése
Költségkezelés

Architecture

Az ábrán két csatlakoztatott virtuális hálózat látható. A központi virtuális hálózat tartalmazza az Azure Firewall-t, az Azure Bastion-t, és egy átjáróalhálózatot, amely a helyszíni rendszerhez kapcsolódik. A spoke virtuális hálózat több alhálózatot, az AKS-fürtöt és a csomópontkészleteket tartalmaz. A virtuális hálózatok egymáshoz kapcsolódása kétirányú kapcsolaton keresztül köti össze az agy és küllő virtuális hálózatokat. A nyilak a Key Vault és a Tárolóregisztrációs adatbázisból Private Link végpontok alhálózatára mutatnak. Az Azure Bastion alhálózatból (felügyelet) a küllő virtuális hálózat belső terheléselosztóhoz mutat egy nyíl. Egy nyíl a helyszíni hálózatról a helyszíni átjáróra mutat. Egy kétirányú nyíl, amelyen a virtuális hálózati társviszony felirat látható, a központi virtuális hálózattól a távoli irodai hálózat küllőjéig mutat. Egy nyíl az internetről a Azure Application Gateway alhálózatra mutat. Egy nyílpont alkotja az AKS-fürtöt a Azure Monitor munkaterület szakaszhoz, amely metrikákat és felügyelt Prometheust tartalmaz.

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

További információ: Hub küllős hálózati topológia Azure.

Hálózati topológia

Ez az architektúra küllős hálózati topológiát használ. Helyezze üzembe a központot és a küllőket különálló virtuális hálózatokban, amelyek virtuális hálózat-kapcsolat révén csatlakoznak. Ez a topológia számos előnnyel rendelkezik:

• Szegregált felügyelet engedélyezése. Alkalmazhatja a szabályozást, és betarthatja a minimális jogosultság (PoLP) elvét. Az Azure landing zóna fogalmát is támogatja a feladatok elkülönítésével.

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

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

• Használjon egy web application firewall szolgáltatást, amely segít az összes webalkalmazás HTTP-forgalomának vizsgálatában.

• 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 vállalati szintű telepítési zónához.

Központi virtuális hálózat

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

• Azure Firewall olyan globális tűzfalszabályzatokkal, amelyeket a központi informatikai csapatok a szervezeti szintű szabályok kikényszerítéséhez határoznak meg

• Azure Bastion, amely biztonságos alagutat hoz létre a magánhálózat határfelületén, ezáltal lehetővé teszi a klaszterkezelési műveletek végrehajtását.

• Átjáróalhálózat VPN-kapcsolathoz

• 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.

Az Azure Firewall-t fogadó alhálózat

Azure Firewall egy felügyelt tűzfalszolgáltatás. A Azure Firewall-példány biztosítja a kimenő hálózati forgalmat. A biztonsági réteg nélkül a forgalom egy rosszindulatú, nem Microsoft szolgáltatással kommunikálhat, amely bizalmas számítási feladatok adatait képes kiszűrni. A Azure Firewall Manager használatával központilag üzembe helyezhet és konfigurálhat több Azure Firewall-példányt, és kezelheti a Azure Firewall szabályzatokat ehhez a hub virtuális hálózathoz 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.

Az Azure Bastion-t fogadó alhálózat

Ez az alhálózat Azure Bastion használatos. Az Azure Bastion használatával biztonságosan hozzáférhet Azure erőforrásokhoz anélkül, hogy az erőforrásokat az internetre tárja. Ez az infrastruktúra az Azure Bastion-t használja az AKS-fürt API-kiszolgálójához való biztonságos csatlakozáshoz, a felügyeleti műveletek végrehajtásához. Az alhálózat csak felügyeletre és műveletekre használható.

Virtuális küllő hálózat

A spoke-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 Application Gateway kiszolgálására szolgáló alhálózat

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 Azure Web Application Firewall. Web Application Firewall biztonságossá teheti 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ése 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. A Azure belső terheléselosztók ebben az alhálózatban találhatók. További információ: A belső load balancer AKS.

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.

Alhálózat Azure Private Link végpontok üzemeltetéséhez

Hozzon létre Azure Private Link kapcsolatokat Azure Container Registry és Azure Key Vault számára, hogy a felhasználók a küllős virtuális hálózaton private végponton keresztül érhessék el ezeket a szolgáltatásokat. 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ózatban. Az alapkonfigurációban a végpontok a küllős virtual network belül egy dedikált alhálózatra lesznek üzembe helyezve. Ez a megközelítés csökkenti a társhálózati hálózati kapcsolaton áthaladó forgalmat. A fürthöz tartozó erőforrásokat ugyanabban a virtuális hálózatban tartja. Az alhálózat szintjén részletes biztonsági szabályokat is alkalmazhat hálózati biztonsági csoportok (NSG-k) használatával.

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

Az AKS API-kiszolgáló alhálózata

Konfigurálhat egy AKS-fürtöt úgy, hogy az API-kiszolgáló virtuális hálózati integrációját használja, amely a fürt API-kiszolgáló végpontját a virtuális hálózatában lévő delegált alhálózatba vetíti. Ezt a konfigurációt privát fürtnek nevezzük, mert biztosítja, hogy az API-kiszolgáló, a csomópontkészletek és a csatlakoztatott ügyfelek közötti összes forgalom teljes egészében a magánhálózaton belül maradjon.

Az AKS által felügyelt Kubernetes API-kiszolgáló és az ügyfelek (mind a fürt belső, mind a külső ügyfelek) közötti kommunikáció egy megbízható hálózatra korlátozódik.

Privát fürt esetén az NSG-k és más beépített hálózati vezérlők használatával biztosíthatja a környezet védelmét. Ez a konfiguráció tiltja az internet és a környezet közötti jogosulatlan nyilvános hozzáférést. További információ: Hozzon létre egy privát AKS-fürtöt.

IP-címek tervezése

Az ábrán egy egyszerű küllős AKS hálózati topológia látható. A központ Azure Firewall, Azure Bastion és átjáróval rendelkezik. A küllő alhálózatokkal rendelkezik a Application Gateway, a bejövő forgalom, a csomópontok, az API-kiszolgáló és a privát végpontok számára. A nyilak az internetről az Application Gateway-ra, majd a belső terheléselosztóra, a bejövő forgalomvezérlőre és a számítási feladatokat végző podokra irányuló forgalmat jelenítik meg. A kimenő nyilak a fürtből az Azure Firewallhoz mennek. A privát végpontok nyilai az Azure szolgáltatásokhoz mennek, például a Konténerregiszterhez és a Kulcstárhoz.

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

Ez a referenciaarchitektúra több hálózati megközelítést használ, amelyek mindegyike IP-címteret igényel:

• A Azure virtuális hálózat, amelyet olyan erőforrásokhoz használ, mint a fürtcsomópontok, a fürt API-kiszolgálója, a Azure-szolgáltatások privát végpontjai és az Application Gateway.

• A fürt Azure Container Networking Interface (CNI) átfedést használ, amely az IP-címeket külön címtérből a Azure virtuális hálózatba foglalja le.

Virtuális hálózati IP-címtér

A Azure 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 entitások IP-címeit. A Azure virtuális hálózat IP-címeinek tervezésekor vegye figyelembe a következő szempontokat:

• Frissítések: Az AKS rendszeresen frissíti a csomópontokat, hogy a mögöttes virtuális gépek up-to-date állapotban legyenek a biztonsági funkciók és más rendszerjavítások esetében. 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ópont egy IP-címet kap a fürt alhálózatától. Győződjön meg arról, hogy elegendő címtér áll rendelkezésre az ideiglenes csomópont IP-címeihez.

  Ebben az architektúrában a podok ip-címeket foglalnak le a Azure CNI overlay pod címteréből, beleértve a működés közbeni frissítéseket is. Ez a megközelítés csökkenti a Azure virtuális hálózatban használt IP-címek teljes számát a többi Kubernetes-hálózatkezelési megközelítéshez képest.

• Skálázhatóság: Vegye figyelembe a rendszer- és felhasználói csomópontok teljes számát, valamint azok maximális méretezhetőségi korlátait. Ha például 400%-kal szeretné felskálázni a rendszert, az összes felskálázott csomópont számára négyszeresére van szükség címekből.

  Mivel ez az architektúra Azure CNI-átfedést használ, a podok méretezhetősége nem befolyásolja a virtuális hálózat címterét.

• Private Link címek: Vegyük figyelembe a más Azure szolgáltatásokkal való kommunikációhoz szükséges címeket a Private Link-en keresztül. Ez az architektúra két címet jelöl ki a tárolóregisztráció és a Key Vault linkjeihez.

• Private fürt API-kiszolgáló címei: Az API-kiszolgáló virtuális hálózat integrációja segít vetít az AKS API-kiszolgálót végpontként a virtuális hálózaton belül. Ehhez a funkcióhoz minimum alhálózatméretre van szükség, ezért a hálózattervezés során győződjön meg arról, hogy megfelel ezeknek az előfeltételeknek.

• Megőrzött IP-címek: Azure a -specifikus címeket használja. 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. Ez az elkülönítés több kisebb méretű alhálózatot eredményez. A bejövő erőforrás is összetettebb lehet. Ennek eredményeképpen előfordulhat, hogy több bejövő vezérlőre van szükség, amelyek mindegyike további IP-címeket igényel.

Pod IP-címterülete

Azure CNI Overlay egy dedikált címtér használatával rendeli hozzá az IP-címeket a podokhoz, amely eltér a virtuális hálózaton használt címtértől. Használjon olyan IP-címteret, amely nem fedi át a virtuális hálózatot vagy bármely peeringelt virtuális hálózatot. Ha azonban több AKS-fürtöt hoz létre, biztonságosan használhatja ugyanazt a podcímteret az egyes fürtökön.

Azure CNI Overlay minden csomópontnak egy /24 címteret rendel a podjaihoz. Fontos gondoskodni arról, hogy a podcímtér elég nagy legyen. Adjon meg annyi /24 blokkot, amennyi a fürt csomópontjainak számához szükséges. Ne felejtse el belefoglalni a frissítések vagy a vertikális felskálázási műveletek során létrehozott ideiglenes csomópontokat. Ha például /16 címteret használ az osztály nélküli tartományközi útválasztási (CIDR) tartományhoz, a fürt körülbelül legfeljebb 250 csomópontra nőhet.

Minden csomópont legfeljebb 250 podot támogat, és ez a korlát a frissítések során ideiglenesen létrehozott podokat is magában foglalja.

További információ: az IP-cím tervezésének útmutatója Azure CNI-átfedéshez.

Egyéb IP-címtérbeli szempontok

Az architektúra teljes hálózatkezelési szempontjait a AKS alaphálózati topológiája című témakörben talál. Az AKS-fürtök IP-címzésének megtervezéséről további információkért lásd: Configure Azure CNI networking in AKS.

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ú funkcióitól és az AKS-bővítményektől függ. Vegye figyelembe a következő különbségeket az előzetes verziójú funkciók és a bővítmények között:

• Az AKS-csapat az előzetes verziójú funkciókat kiküldöttnek és fejlődőnek ismerteti, mivel ezek a funkciók általában csak néhány hónapig maradnak ebben az állapotban, mielőtt az általánosan elérhető (GA) fázisba kerülnének.

• Az AKS add-ons é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.

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ékkel bírnak egy általános célú fürthöz. Mivel ezek a funkciók kikerülnek az előzetes verzióból, ennek megfelelően módosul az alaparchitektúra. 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, ami magában foglalja 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.

Konténerkép-referencia

A klaszter tartalmazhatja a számítási feladatot és számos más rendszerképet, például az ingress kontrollert. Előfordulhat, hogy a képek némelyike nyilvános regisztrációs adatbázisokban található. A rendszerképek fürtbe való beemelésekor vegye figyelembe a következő szempontokat:

• A fürt hitelesítése szükséges az image lekéréséhez.

• Ha nyilvános rendszerképet használ, importálja a rendszerképet egy konténer-regisztrációs tárolóba, amely megfelel a szolgáltatásiszint-célkitűzésnek (SLO). 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, üzemeltetési problémák léphetnek fel. Fontolja meg a privát tárolóregisztrációs adatbázis (például Azure Container Registry) nyilvános beállításjegyzék helyett való használatának alábbi előnyeit:

  • Letilthatja a képekhez való jogosulatlan hozzáférést.
  • Nincsenek a nyilvánosság számára elérhető függőségei.
  • A képek letöltési naplóihoz férhet hozzá, hogy nyomon kövesse a tevékenységeket, és osztályozza a kapcsolati problémákat.
  • 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 a Azure Policy keresztül kényszerítheti ki. Ebben a referencia-implementációban a fürt csak a fürttel együtt üzembe helyezett dedikált Azure Container Registry példányról tölti le a lemezképeket.

Az alapfürt számítási erőforrásainak konfigurálása

Az AKS-ben minden csomópontkészlet általában egy virtuális gép méretezési csoporthoz van leképezve. A csomópontok minden csomópontkészletben virtuális gépek (VM-ek).

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 D2dv5-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 rövid élettartamú lemeze 64 GB.

A felhasználói csomópontkészlet kapacitásának tervezésekor vegye figyelembe a következő javaslatokat:

• 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 monitorozá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ó: Sizes for VMs in Azure.

• Helyezzen üzembe legalább két csomópontot, hogy a számítási feladat egy magas rendelkezésre állási mintát kövessen 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 a D4dv5 termékváltozatot használja az éles számítási feladatokhoz.

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

• Állítsa be az egyes csomópontok maximális podjait a kapacitástervezés alapján. Ha megpróbál létrehozni egy kapacitás-alapkonfigurációt, 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-cím korlátozásai alapján.

Az operációs rendszer kiválasztása

A legtöbb AKS-fürt linuxos operációs rendszert használ a csomópontkészletekhez. Ebben a referencia-implementációban az Azure Linux-t használjuk, amely egy könnyű, edzett Linux-disztribúció, és kifejezetten Azure-hoz van hangolva. Választhat másik Linux-disztribúciót, például az Ubuntu-t, ha szeretné, vagy ha Azure Linux nem felel meg a követelményeknek. Ha másik operációs rendszert választ, győződjön meg arról, hogy az operációsrendszer-lemez mérete megfelelő a lemezképhez. Egyes disztribúciók több helyet igényelnek, mint a Linux Azure, ezért előfordulhat, hogy növelnie kell a lemez méretét az üzembe helyezési vagy futásidejű problémák elkerülése érdekében.

Ha a számítási feladat vegyes technológiákból áll, különböző operációs rendszereket használhat különböző csomópontkészletekben. Ha azonban nincs szüksége különböző operációs rendszerekre, javasoljuk, hogy az összes számítási feladatcsomópont-készlethez egyetlen operációs rendszert használjon a működési összetettség csökkentése érdekében.

A fürt Microsoft Entra ID integrálása

A fürtbe és a fürtből való hozzáférés biztosítása kritikus fontosságú. A fürt szemszögéből megismerheti a belső-külső és külső-belső forgalom közötti különbséget:

• Belülről kifelé történő hozzáférés: Fontolja meg az AKS hozzáférést Azure összetevőkhöz, például a hálózati infrastruktúrához, a Tárolóregisztrációhoz és a Key Vaulthoz. Csak azokat az erőforrásokat engedélyezze, amelyekhez a fürt hozzáférhet.

• Kívülről befelé irányuló hozzáférés: Adjon azonosítóknak hozzáférést 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 Azure Resource Manager.

AKS-hozzáférés Azure összetevőkhöz

Az AKS kezelése a Microsoft Entra ID-n keresztül kétféleképpen lehetséges az Azure-hoz való hozzáférés érdekében: szolgáltatási hitelesítő adatokkal vagy felügyelt identitásokkal az Azure erőforrások esetén.

A Azure AKS-hozzáférésének kezelésére szolgáló két módszer közül a felügyelt identitásokat javasoljuk. A szolgáltatási főfelhasználók esetében manuálisan vagy programozott módon kell kezelnie és forgatnia a titkos kulcsokat. Felügyelt identitásokkal a Microsoft Entra ID kezeli és végrehajtja a titkos kulcsok hitelesítését és időben történő cseréjét.

Javasoljuk, hogy engedélyezze és használja felügyelt identitásokat az AKS-ben hogy a fürt Microsoft Entra ID keresztül kommunikálhasson a külső Azure erőforrásokkal. Ha nem használja azonnal Microsoft Entra ID integrációt, később is hozzáadhatja.

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 Registryvel hitelesíti magá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 regiszter hitelesítő adatait, ami úgy történik, hogy hozzáférést ad AcrPull a fürt kubelet által kezelt identitásának a regiszterhez. Ha nem használ felügyelt identitást, ezeket az adatokat tárolhatja egy Kubernetes-titokban, és imagePullSecrets használhatja annak lekérdezésére. Ezt a megközelítést nem javasoljuk, mert biztonsági összetettségeket vezet be, beleértve a titkos kód előzetes ismeretének szükségességét és a DevOps-folyamatban való tárolását. Emellett működési többletterhelést is hozzáad, mert el kell forgatnia a titkos kulcsot.

Ebben az architektúrában a fürt olyan Azure erőforrásokhoz fér hozzá, amelyeket a Microsoft Entra ID biztosít, és a felügyelt identitásokat támogató műveleteket hajt végre. Rendeljen hozzá Azure szerepköralapú hozzáférés-vezérlést (Azure RBAC) és engedélyeket a fürt felügyelt identitásaihoz, a fürt által végzett műveletektől függően. A fürt hitelesíti magát a Microsoft Entra ID, majd a hozzá rendelt szerepkörök alapján engedélyezi vagy megtagadja a hozzáférést. Íme néhány példa a referencia-implementációból, ahol az Azure beépített szerepkörei vannak hozzárendelve a klaszterhez:

• A Network közreműködői szerepkör kezeli a fürt sugárirányú virtuális hálózatának vezérlésének lehetőségét. Ezzel a szerepkör-hozzárendeléssel az AKS-fürt rendszerhez hozzárendelt identitás együttműködhet a belső bejövőforgalom-vezérlő szolgáltatás dedikált alhálózatával és az AKS privát API-kiszolgálóval.

• A Private DNS zóna közreműködői szerepköre kezeli a fürt azon képességét, hogy a zónát közvetlenül a fürtöt üzemeltető küllős virtuális hálózathoz kapcsolja. A privát fürtök egy private DNS zóna használatával távol tartják a DNS-rekordokat a nyilvános internetről. Továbbra is lehet létrehozni privát AKS-fürtöt nyilvános DNS-címmel. Javasoljuk, hogy explicit módon tiltsa le ezt a funkciót azáltal, hogy enablePrivateClusterPublicFQDNfalse beállítja, így megakadályozva a vezérlősík magánhálózati IP-címének közzétételét. Fontolja meg a Azure Policy használatát a nyilvános DNS-rekordok nélküli privát fürtök használatának kényszerítéséhez.

• A Monitoring Metrikák Közzétevő szerepkör kezeli a fürt azon képességét, hogy metrikákat küldjön az Azure Monitorba.

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

Fürt hozzáférés

Microsoft Entra integráció 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 az ön identitását az Azure szerepkörök ellenében hitelesíti, amelyek engedélyezettek a fürt hitelesítő adatainak lekérésére. További információért tekintse meg a következőt: Elérhető klaszterszerepkörök engedélyei.

Az AKS támogatja a Kubernetes-hozzáférést a Microsoft Entra ID segítségével, amely az identitásszolgáltatóként van integrálva a natív Kubernetes RBAC-vel, vagy a natív Azure RBAC használatával a fürthozzáférés vezérlésére. A következő szakaszok mindkét megközelítést részletesen ismertetik.

A Kubernetes RBAC társítása a Microsoft Entra ID-vel

A Kubernetes a következő API-objektumokon keresztül támogatja az RBAC-t:

• Engedélykészlet, amelyet egy Role vagy ClusterRole objektummal fürt-szintű engedélyekhez definiálsz.

• Olyan hozzárendelések, amelyek felhasználókat és csoportokat rendelnek hozzá, akik jogosultsággal rendelkeznek a műveletek végrehajtására. Kötéseket definiáljon a RoleBinding vagy ClusterRoleBinding objektum használatával.

A Kubernetes rendelkezik néhány beépített szerepkörrel, mint például a fürt-rendszergazda, a szerkesztő és a megtekintő. Kösse ezeket a szerepköröket Microsoft Entra felhasználókhoz és csoportokhoz a vállalati címtár használatával a hozzáférés kezeléséhez. További információért lásd: Kubernetes RBAC használata 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 is belefoglalja a Microsoft Entra hozzáférési felülvizsgálatokba.

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

Javasoljuk, hogy Azure RBAC és Azure szerepkör-hozzárendelések használatával kényszerítse ki a fürt engedélyezési ellenőrzését. Ez az engedélyezési módszer integrálható Microsoft Entra hitelesítéssel. Szerepköröket különböző hatókörökhöz rendelhet, például a felügyeleti csoporthoz, az előfizetéshez vagy az erőforráscsoporthoz. A hatókör alá tartozó összes fürt ezután örökli a konzisztens szerepkör-hozzárendelés készletet tekintve, hogy kinek van engedélye a Kubernetes-fürt objektumainak elérésére.

Nem javasoljuk a Kubernetes-natív RBAC-nak a használatát a ClusterRoleBindings és a RoleBindings esetén.

További információ: Azure RBAC kubernetes-engedélyezéshez.

Helyi fiókok

Az AKS támogatja a natív Kubernetes felhasználói 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óján kívül történik, ami megnehezíti a központosított felhasználói hozzáférés-ellenőrzést és szabályozást. A fürthöz való hozzáférést mindig Microsoft Entra ID használatával kezelheti, és konfigurálhatja a fürtöt úgy, hogy explicit módon tiltsa meg a helyi fiókhoz való hozzáférést.

Ebben a referenciamegvalósításban a helyi klaszterfiókokhoz való hozzáférés kifejezetten tilos, amikor a rendszer üzembe helyezi a klasztert.

Microsoft Entra ID integrálása a számítási feladathoz

A teljes fürthöz Azure rendszer által hozzárendelt felügyelt identitáshoz hasonlóan 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 Microsoft Entra ID keresztül férhessen hozzá az erőforrásokhoz. Tegyük fel például, hogy a munkaterhelés az Azure Storage-ban tárolja a fájlokat. Amikor hozzá kell férnie ezekhez a fájlokhoz, a pod Azure felügyelt identitásként hitelesíti magát az erőforráson.

Ebben a referencia-implementációban az AKS-en a Microsoft Entra Workload 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. További információkért lásd: Számítási feladat identitásfederáció.

Hálózati modell kiválasztása

Az AKS a Container Networking Interface (CNI) beépülő modulokat két hálózati modellben biztosítja: átfedéses és lapos. Mindkét modell támogatja a hálózati szabályzatokat a fürtön belüli forgalom kezeléséhez.

Egy lapos hálózati pluginnal, mint például az Azure CNI Pod Subnet, minden pod kap egy IP-címet a virtuális hálózati alhálózatból. Az ugyanabban a hálózatban vagy társhálózatban lévő erőforrások közvetlenül az IP-címük alapján férhetnek hozzá a podokhoz hálózati címfordítás (NAT) nélkül. Használjon lapos hálózatkezelési modellt, ha a számítási feladathoz a podok közvetlenül a virtuális hálózatról irányíthatók.

Ez a referencia-implementáció Azure CNI Overlay-t használ, amely egy átfedéses hálózati beépülő modul. A virtuális hálózati IP-címeket csak csomópontokhoz rendeli, és pod IP-címeket rendel hozzá egy külön CIDR-tartományhoz. Mivel Azure CNI-átfedés sokkal kevesebb virtuális hálózati IP-címet használ fel, mint a sima modellek, a legtöbb üzembe helyezéshez javasoljuk.

A modellekről további információt az AKS CNI hálózatkezelési áttekintésében és az AKS hálózati kapcsolatának és biztonságának ajánlott eljárásaiban talál.

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

A Kubernetes ingress források kezelik a bejövő forgalom útválasztását és elosztását a klaszter számára. A bejövő erőforrásoknak két része van:

• Az AKS által kezelt belső load balancer: A load balancer egy privát statikus IP-címen keresztül teszi elérhetővé az ingress vezérlőt. Egyetlen kapcsolattartó pontként szolgál, amely bejövő folyamatokat fogad.

  Ez az architektúra Azure Load Balancer használ. 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 a Application Gateway, és a kommunikáció az átviteli réteg biztonságán (TLS) keresztül történik. A bejövő forgalom TLS-titkosításával kapcsolatos további információkért tekintse meg a bejövő forgalom folyamatának szakaszát.

• A bejövőforgalom-vezérlő: Ez a példa a Traefiket használja. A felhasználói csomópontkészletben fut a fürtön belül. A belső load balancer fogadja a forgalmat, 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. podAntiAffinity erre a célra használható.

• Korlátozza a podok ütemezését, hogy azok csak a felhasználói csomópontkészletre kerüljenek a(z) nodeSelectors használatával. 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 Gateway-től kap forgalmat.

• Konfigurálja a readinessProbe és livenessProbe beállításokat, amelyek a megadott időközönként figyelik a podok egészségi állapotát. 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ő access adott erőforrásokra való korlátozását és a végrehajtható műveletek korlátozásá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.

Note

Válasszon egy megfelelő bejövőforgalom-vezérlőt a követelmények, a számítási feladatok, a csapat készségkészlete és a technológiai lehetőségek támogatottsága alapján. A legfontosabb, hogy a bejövőforgalom-vezérlőnek meg kell felelnie az SLO elvárásainak.

A Traefik egy nyílt forráskódú lehetőség egy Kubernetes-fürthöz, és ebben az architektúrában szemléltető célból szerepel. Nem-Microsoft termékek integrációját jeleníti meg az Azure szolgáltatásokkal. Az implementáció bemutatja, hogyan integrálható például a Traefik a Microsoft Entra Workload ID-val és a kulcstartóval.

Használhatja a Application Gateway bejövőforgalom-vezérlőt is, amely jól integrálható az AKS-sel. Application Gateway a bejövőforgalom-vezérlői szerepkörön túli előnyöket is biztosít. Ez a fürt virtuális hálózati belépési pontja, és megfigyelheti a fürtbe érkező forgalmat. Használja Application Gateway, ha az alkalmazáshoz web application firewall szükséges. Lehetővé teszi a TLS leállítását is.

Router 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 a Application Gateway alhálózatbó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ő típusú forgalmat tartalmazza:

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

• Kimenő forgalom a fürtben lévő podból vagy csomópontból egy külső szolgáltatás felé.

• 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.

Az ábra három különböző forgalmi mintát mutat be az architektúrán belül. A központi hálózat Azure Firewall, Azure Bastion, átjáróval és Azure Monitor rendelkezik. A spoke hálózatban az AKS-fürt az Application Gateway található a belépési pontnál. A zöld nyilak az internetről érkező bejövő forgalmat az Application Gateway-en, a belső terheléselosztón, az ingress controlleren, és végül a számítási feladat podokon keresztül jelenítik meg. A narancssárga nyilak a podok közötti forgalmat jelenítik meg a fürtben. A piros nyilak a fürtről az Azure Firewall felé irányuló kimenő forgalmat jelenítik meg. A privát végpontok nyílbillentyűi a Tárolóregisztrációs adatbázisra és Key Vault mutatnak.

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 Application Gateway két különböző TLS-tanúsítvány használatával történik, ahogyan az alábbi ábrán látható.

Az ábrán végponttól végpontig terjedő TLS-forgalom látható, amely az ügyféltől a munkaterhelésig tart. Az ügyfél HTTPS-forgalmat küld a Application Gateway. A Key Vault és az Application Gateway közötti nyíl a tanúsítványlekérést jeleníti meg. Application Gateway leállítja a TLS-t, majd újra titkosítja a belső load balancer felé irányuló forgalmat (HTTPS). A Key Vault és az ingress controller közötti másik nyíl jelzi a tanúsítvány CSI-illesztőprogramon keresztüli lekérését. A belső load balancer továbbítja a titkosított forgalmat a bejövő forgalomvezérlőnek, amely leállítja a TLS-t. Az utolsó nyíl az HTTP-forgalmat jeleníti meg az ingress vezérlőtől a munkaterhelés podjaiig. Minden TLS-végpont meg van jelölve.

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 a 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ás-tűzfallal rendelkezik, és lefolytatja a TLS kézfogást a bicycle.contoso.com számára, így csak biztonságos titkosításokat engedélyez. Application Gateway egy TLS-végpont, amely azért fontos, mert Application Gateway web application firewall ellenőriznie kell a egyszerű szöveges kérést és választ. 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álható a Application Gateway. További információ: TLS-leállítás Key Vault tanúsítványokkal.

   Application Gateway feldolgozza web application firewall ellenőrzési szabályokat, és olyan útválasztási szabályokat futtat, amelyek továbbítják a forgalmat a konfigurált háttérrendszerbe.

3. Amikor a forgalom az Application Gateway-en keresztül a háttérrendszerbe kerül, újra titkosítja a rendszer egy másik TLS-tanúsítvánnyal, amely egy helyettesítő tanúsítvány a *.aks-ingress.contoso.com számára, mivel ez továbbítódik a belső load balancer felé. Ez az újrakezelés titkosítással biztosítja, hogy a nem biztonságos forgalom ne áramoljon a klaszter alhálózatába.

4. A bejövő forgalmat kezelő vezérlő a terheléselosztón keresztül fogadja a titkosított forgalmat. A vezérlő egy másik TLS-végpont a(z) *.aks-ingress.contoso.com számára, és HTTP-n keresztül továbbítja a forgalmat a számítási feladat podjaira. A tanúsítványok tárolása Key Vault történik, é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 Web Application Firewall védelemmel. Ez a megközelítés minimálisra csökkenti a többletterhelést a számítási feladatok felügyeletében és a gyenge hálózati teljesítményből adódó túlterhelést. A számítási feladatok és a megfelelőségi követelmények határozzák meg, hogy hol hajtja végre TLS-leállítást.

Kimenő forgalom folyamata

Ebben az architektúrában azt javasoljuk, hogy a fürtből érkező összes kimenő forgalom haladjon át az Azure Firewallon. Használhatja saját hasonló hálózati virtuális berendezését is. Nem ajánlunk más kimenő beállításokat, például Azure NAT Gateway vagy HTTP-proxyt mert nem biztosítanak hálózati forgalomvizsgálatot. Az Zero Trust vezérléshez és a forgalom vizsgálatának képességéhez küldje el az összes kimenő forgalmat Azure Firewall keresztül. Implementálja ezt a konfigurációt felhasználó által megadott útvonalakkal (UDR-ekkel). Az útvonal következő ugrása a Azure Firewall private IP-címe. Azure Firewall dönti el, hogy a meghatározott szabályok vagy a beépített fenyegetésfelderítési szabályok alapján blokkolja vagy engedélyezi-e a kimenő forgalmat.

A Azure Firewall másik lehetősége a AKS HTTP-proxy funkció használata. A fürtön kívülre irányuló összes forgalom a HTTP-proxy IP-címére kerül, amely azt továbbítja vagy eldobja.

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

Note

Ha nyilvános terheléselosztót használ nyilvános pontként a bejövő forgalomhoz és a kimenő forgalomhoz Azure Firewall UDR-ek használatával, aszimmetrikus útválasztási forgatókönyv jelenhet meg. Ez az architektúra belső terheléselosztókat használ a Application Gateway mögötti dedikált bejövő alhálózatban. Ez a kialakítási lehetőség növeli a biztonságot, és kiküszöböli az aszimmetrikus útválasztással kapcsolatos problémákat is. Vagy átirányíthatja a bejövő forgalmat a tűzfalon Application Gateway előtt vagy után, de ez a megközelítés a legtöbb esetben nem szükséges, és nem javasoljuk. Az aszimmetrikus útválasztásról további információt az Azure standard terheléselosztó integrálása a tűzfallal című témakörben talál.

A Zero Trust vezérlés kivétele az, amikor 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 konténer-regisztrációból, vagy bizalmas adatokat kell letöltenie a Key Vaultból. Ezekben a forgatókönyvekben a Private Link használatát javasoljuk.

A Private Link használatának 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 Link a célszolgáltatás nyilvános végponton való használata helyett további konfigurációra van szükség. Emellett nem minden Azure szolgáltatás vagy termék támogatja a Private Link. 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 Private Link 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 Azure Firewall szabályokon és a célszolgáltatásba beépített tűzfalon keresztül szabályozhatja a hozzáférést. Mivel ez a forgalom a tűzfal statikus IP-címén halad át, felveheti ezeket a címeket a szolgáltatás IP-engedélyezési listájába.

Az Azure-szolgáltatásokhoz nyilvános végpontokon keresztüli csatlakozás egyik hátránya, hogy Azure Firewall ezután több szabályra van szükség annak biztosításához, hogy csak egy adott alhálózatról érkező forgalmat engedélyezi. Vegye figyelembe ezeket a címeket, ha több IP-címet szeretne használni a kimenő forgalomhoz Azure Firewall. Ellenkező esetben elérheti a portok kimerülését. További információ a több IP-cím tervezéséről: Több IP-címmel rendelkező Azure Firewall létrehozása.

Pod–Pod forgalom

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

A fürt beállításakor engedélyezze a hálózati házirendet, mert később nem lehet hozzáadni. Az NetworkPolicy technológiák implementálására több lehetőség közül választhat. Javasoljuk, Azure hálózati házirendet, amelyhez Azure CNI szükséges. 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. A Calico-t nem fedi a standard Azure támogatás.

További információ: Differenciák Azure hálózati házirendmotorok 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 kezelési műveleteket szeretnének végrehajtani 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éseket. Ilyen erőforrások például a buildügynök-készlet egy DevOps-folyamatban, egy Azure Bastion példány a 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, javasoljuk, hogy állítson be egy privát AKS-fürtöt.

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

Javasoljuk, hogy az AKS-fürtöt privát fürtként telepítse. Minden vezérlősík- és csomópontkészlet-forgalom a magánhálózaton marad, és nem lesz elérhető a nyilvános interneten. Ez a referencia-implementáció úgy állít be egy privát fürtöt, hogy az API-kiszolgálót integrálja a virtuális hálózattal. Az alacsonyabb környezetek a kényelem érdekében megfontolhatják a privát fürtjavaslat enyhítését. Az éles AKS-fürtöket azonban mindig magánfürtként kell üzembe helyezni a biztonságos üzembe helyezési alapkonfiguráció érdekében.

A privát AKS-fürtökre jutó forgalom származhat a csatolt virtuális hálózatból, a társhálózatokból vagy a távoli hálózatok privát végpontjaiból. Bár az AKS-csomópontok természetesen a küllőn élnek, a felügyeleti feladatokat végző operátorok dedikált hálózati útvonalat igényelnek az AKS API-kiszolgáló privát eléréséhez. Ezt a kapcsolatot a következő módokon hozhatja létre:

• Tunnelling: Az Azure Bastion használatával nyisson alagutat közvetlenül a fürt API-kiszolgálójához.
• Jump-box: Jump-box virtuális gép kiépítése, és az Azure Bastion használatával SSH-n vagy RDP-n keresztüli csatlakozás. Innen az operátor kéréseket küld a fürt API-kiszolgálójára a privát IP-címén keresztül.

A referencia-implementációban Azure Bastion használunk az AKS API-kiszolgálóhoz való bújtatáshoz a fürtkezelési műveletek végrehajtásakor. Ez a megközelítés általában egyszerűbben kezelhető, kevésbé költséges, mint egy jump-box virtuális gép üzembe helyezése és kezelése, és kevésbé összetett a több operátor közötti koordinációhoz. Az alábbi követelmények bármelyike esetén azonban választhatja a jump-box virtuális gép használatát:

• Az operátorok nem biztonságos eszközöket használnak. A jump-box virtuális gépek erősebb biztonsági szigorítást biztosíthatnak, ha az ügyféleszközök nem megbízhatók.
• Az operátorok instabil hálózatokon keresztül csatlakoznak. A jump-box virtuális gépek stabilabb kapcsolatot biztosíthatnak a fürthöz, különösen a hosszú ideig futó vagy kötegkezelési műveletekhez.
• Az operátorok speciális diagnosztikai eszközöket használnak. Előfordulhat, hogy a diagnosztikai eszközök bizonyos típusai, például a csomagrögzítés nem működnek megfelelően a tunneling módszerekkel.

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

Titkos kulcsokat tárol egy felügyelt kulcstárolóban, például Key Vault. 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ési naplót biztosít. Emellett az alapvető titkos adatokat is elkerülíti az üzembehelyezési folyamatból. Ebben az architektúrában egy Key Vault tűzfal van engedélyezve és konfigurálva, és a Private Linket használják az Azure erőforrásokhoz való csatlakozásra, mint például a Key Vault számára a titkokhoz és tanúsítványokhoz való hozzáféréshez.

Key Vault jól integrálva van más Azure szolgáltatásokkal. A szolgáltatások beépített funkciójával hozzáférjen titkokhoz. Application Gateway bejövő forgalmi áramlathoz való TLS-tanúsítvány hozzáféréséről a Bejövő forgalmi áramlás részben talál bővebb információt.

A Key Vault Azure RBAC-engedélymodellje lehetővé teszi, hogy a munkafolyamatok identitásait a Key Vault Titkos információk felhasználója vagy a Key Vault Olvasó szerepköréhez rendeljék, és hozzáférjenek a titkokhoz. További információ: Access Key Vault Azure RBAC használatával.

Hozzáférés a fürt titkaihoz

A munkaterhelés identitásai használatával engedélyeznie kell, hogy egy pod hozzáférjen titkos adatokhoz egy adott tárolóból. A lekérési folyamat megkönnyítése érdekében használjon egy titoktá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 Vault titkos kulcstár CSI-illesztőprogramjával használja. A bővítmény lekéri a TLS-tanúsítványt a Key Vaultból, és betölti az illesztőprogramot abba a podba, amely a bejövő forgalmat vezérlő rendszert futtatja. 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.

Terhelés tárolás

Az architektúra számítási feladatai állapot nélküliek. Ha állapotot kell tárolnia, azt javasoljuk, hogy a fürtön kívül tárolja. 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 alkalmazások számára az AKS-ben.

Szabályzatkezelés

Az AKS-fürt kezelésének hatékony módja az irányítás szabályzatok általi érvényesítése. A Kubernetes az Open Policy Agent (OPA) Gatekeeper használatával implementálja a szabályzatokat. Az AKS-hez az Azure Policy-n keresztül 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ályérvényesítését, és naplózza az összes szabályzat-ellenőrzést. A politikai módosítások nem jelennek meg azonnal a clusterben, így késésekre lehet számítani.

Az AKS-fürtök kezeléséhez többféleképpen is használhatja az Azure Policyt:

• 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 az Azure Policy for Kubernetes segítségével.

Egy gyakori példa arra, hogy egy szabályzat hasznos lehet, a konténer képek szabályozása és érvényesítése körül található. A konténerképek biztonsági rések forrása lehetnek, és egyes szervezetek megkövetelik, hogy a nem megbízható konténerképek egy konténerkép-ellenőrző eszközzel legyenek érvényesítve, majd jóváhagyva, mielőtt gyártási klaszterben használhatók lennének. Ezt a folyamatot a Azure Policy használatával kényszerítheti ki, és letilthatja a nem megbízható tárolólemezképek fürtre való üzembe helyezését. További információ: Kvarantin minta.

Szabályzatok megadásakor alkalmazza őket a munkaterhelés követelményei alapján. Vegye figyelembe az alábbi tényezőket:

• Döntse el, hogy beállítja-e a szabályzatok gyűjteményét, más néven kezdeményezéseket, vagy egyéni szabályzatokat választ. Azure Policy két beépített kezdeményezést biztosít: alapszintű és korlátozott. Minden kezdeményezés az AKS-fürtre 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 az erőforrásokhoz, például a Container Registry, az Application Gateway vagy a Key Vault, amelyek együttműködnek a fürttel. A szervezet követelményei alapján válasszon szabályzatokat.

• Döntse el, hogy ellenőrizni vagy megtagadni kívánja 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. Legyen óvatos, amikor a Megtagadás módot választja, mert az túl korlátozó lehet ahhoz, hogy a számítási feladat működjön.

• Döntse el, hogy vannak-e olyan területek a számítási feladatban, amelyeknek nem kellene a tervezésnek megfelelőnek lenniük. Azure Policy megadhatja azokat a Kubernetes-névtereket, amelyek mentesülnek a szabályzatkényszerítés alól. Javasoljuk, hogy továbbra is alkalmazza a szabályzatokat ellenőrzési módban, hogy tisztában legyen ezekkel az esetekkel.

• Döntse el, hogy vannak-e 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ó: A szabályzatok egyéni definícióinak létrehozása és hozzárendelése.

• Döntse el, hogy rendelkezik-e szervezeti szintű követelményekkel. Ha igen, vegye fel ezeket a szabályzatokat a felügyeleti csoport szintjén. A fürtnek saját feladatspecifikus szabályzatokat kellene megállapítania, még akkor is, ha a szervezet rendelkezik általános szabályzatokkal.

• Döntse el, hogy Azure szabályzatokat kell-e hozzárendelnie adott hatókörökhöz. Győződjön meg arról, hogy a gyártási szabályzatokat a tesztkörnyezet-tel is ellenőrzik. Ellenkező esetben az éles környezetben történő üzembe helyezés során váratlan további korlátozásokba ütközhet, amelyekről nem számolt be az előkészítés során.

Ez a referencia-implementáció lehetővé teszi az Azure Policy használatát az AKS-fürt létrehozásakor. A korlátozó kezdeményezés ellenőrzési módban van hozzárendelve, hogy betekintést nyerjen a nem megfelelőség láthatósága érdekében.

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 képfájlok csak az üzembe helyezett tárolóregisztrációs példányból legyenek letöltve.

Fontolja meg saját egyéni kezdeményezések létrehozását. Egyesítse a munkaterhelésre vonatkozó szabályzatokat egyetlen kiosztásban.

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

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

A növekvő igényeknek megfelelően a Kubernetes azáltal tud kibővülni, hogy több podot ad hozzá a meglévő csomópontokhoz a podok horizontális automatikus skálázása révén. 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 az egyik módszer az, hogy értesítést kapunk, ha hibát jelez a Kubernetes ütemezője. Egy másik módja annak, hogy idővel figyelemmel kísérje a függőben lévő podokat. A csomópontok számát a Azure CLI vagy a Azure portálon módosíthatja.

Javasoljuk, hogy az automatikus skálázási módszert használja, mert a manuális mechanizmusok némelyike beépített az automatikus skálázóba.

Á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.

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, hogy állítsa be a replikák minimális és maximális számá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álatot biztosítjuk natív módon. 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 versenyállapot, például amikor a HPA ellenőrzi, hogy a skálázási művelet befejeződik-e. Az eredmény tehát helytelen arányszámítás lehet. További információ: A skálázási események lehűlési ideje.

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 feladatokat hajtja, ahelyett, hogy a számítási feladat processzorhoz kötött vagy memóriaalapú lenne. 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 a 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 skálázója

A cluster automatikus skálázó 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 beállítása során. Minden felhasználói csomópontkészlethez külön automatikus skálázó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 beállít egy új csomópontot a csomópontkészletben. Ezzel szemben a fürtskálázó ellenőrzi a csomópontok kihasználatlan 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 hatásaitó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.

Ü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ó: Megjelenítések a megbízhatósági célok meghatározásához. Tekintse át az AKS szolgáltatásiszint-szerződésének (SLA) feltételeit a legújabb online szolgáltatások SLÁ-jában szereplő cikkben.

Klaszter csomó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 vagy kapacitásra van szüksége, méretezze felfelé a további csomópontok hozzáadásával.

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észletet a CriticalAddonsOnly taint fertőzött, hogy az alkalmazás podjai ne legyenek ütemezve a rendszercsomópont-készletekben.

A fürt rendszeres fenntartású feladatai, 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

• Pod erőforrás-követelmények megadása: Javasoljuk, hogy adja meg a pod erőforrás-követelményeket a telepítésekben. 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 felfrissítési esemény során. További információ: Pod-megszakítási költségvetés.

  Konfiguráljon több replikát az üzemelő példányban a hardverhibákhoz hasonló fennakadások kezelésére. A tervezett események, például frissítések és fejlesztések esetén a kiesési költségvetés segíthet biztosítani a szükséges pod-replikák számát a várt alkalmazásterhelés 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 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ás-kvóták.

  Note

  Ha a fürt szintjén állít be erőforráskvótákat, problémák léphetnek fel, ha olyan külső számítási feladatokat helyez üzembe, amelyek nem rendelkeznek megfelelő kérésekkel és korlátozásokkal. Ha névtérszinten állít be kvótákat, az biztosítja, hogy azok csak a számítási feladatok összetevőire vonatkozzanak.

• Podkérelmek és korlátok beállítása: Állítsa be a kéréseket és korlátokat, hogy a Kubernetes hatékonyan lefoglalhassa a processzor- és memóriaerőforrásokat a podokhoz. Nagyobb tárolósűrűséget biztosít egy csomóponton. 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 állapítja azt a küszöbértéket, amely instabilitást okoz a fürtben.

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

elérhetőségi zónák

Bizonyos típusú kimaradások elleni védelemhez használja a availability zones, ha a régió támogatja őket. A vezérlősík összetevői és a csomópontkészletek csomópontjai is zónaredundánsak, ami azt jelenti, hogy több zónában vannak elosztva. 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-skálázási csoportra van leképezve, amely kezeli a csomópont példányait és a skálázhatóságot. 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:

• Entire infrastruktúra: Válasszon egy régiót, amely támogatja az elérhetőségi zónákat. További információ: Limitations. Az üzemidős SLA használatához ki kell választania a Standard vagy a Premium szintet. Az üzemidőszolgáltatási szint (SLA) nagyobb, ha elérhetőségi zónákat használ.

• Cluster: Csak akkor állíthat be elérhetőségi zónákat, ha létrehozza a csomópontkészletet. 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 virtuálisgép-méretezési csoport minden zónában azonos hardverkonfigurációt biztosít.

  A zónaredundancia 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 feltétlenül oszlanak el a rendelkezésre állási zónák között.

• Függő erőforrások: Az elérhetőségi zónák használatának rugalmassági előnyeinek kihasználása érdekében minden szolgáltatási függőségnek támogatnia kell a zónákat. 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.

  Tegyük fel például, hogy a számítási feladat olyan adatbázist használ, amely nem zónarugalmas. Ha hiba történik, előfordulhat, hogy az AKS-csomópont egy másik zónába kerül, de az adatbázis nem költözik a csomóponttal az adott zónába, így a számítási feladat megszakad.

Az architektúra egyszerűsége érdekében az AKS egyetlen régióban van üzembe helyezve, három rendelkezésre állási zónára kiterjedő csomópontkészletekkel. Az infrastruktúra egyéb erőforrásai, például a 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ó

Amikor engedélyezi az elérhetőségi zónákat, nem biztosított a megfelelő lefedettség abban a valószínűtlen esetben, ha az egész 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.

• párosított régiókat, 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. Azure gondoskodik arról, hogy egyszerre csak egy régió legyen frissítve a párban. A régiók nem rendelkeznek párokkal. 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 szállítási (CI/CD) folyamat használatát, amelyet úgy konfigurál, hogy egy régióhiba esetén vezényelje a helyreállítást. 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 folyamatos access biztosít a képek számára, 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 Balancer, mert el tudja osztani a nemwebalapú forgalmat a zónák között. Ha régiók közötti forgalmat szeretne elosztani, fontolja meg a Azure Front Door. Más lehetőségekért lásd: Válasszon egy terheléselosztót.

Note

A többrégiós fürtök AKS-alapkonfigurációja példaforgatókönyv kibővíti a cikkben szereplő architektúrát, hogy több régiót is belefoglaljon egy aktív-aktív és magas rendelkezésre állású konfigurációba.

Katasztrófa utáni helyreállítás

Ideális esetben, ha hiba történik az elsődleges régióban, gyorsan válthat egy másik régióban lévő példányra. Lehetséges, hogy előre létrehoz egy fürtöt, vagy megvárja a létrehozását addig, amíg szükség lesz rá. Vegye figyelembe a következőket:

• 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.

• Állítson be minden Azure szolgáltatást 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áját kódként, beleértve az AKS-fürtöt és az összes többi 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.

Klaszter biztonsági mentése

Számos architektúra esetén beállíthat egy új fürtöt, amelyet a GitOps alapú fürtindítással visszaállíthat az üzemeltetési állapotba, majd telepítheti rá az alkalmazásokat. 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ése a helyreállítási stratégia részét kell, hogy képezze, telepítenie kell egy olyan megoldást, amely megfelel a vállalkozás fürtön belüli követelményeinek. Ez az ügynök felelős a fürterőforrás-állapotnak a választott célhelyre való leküldéséért, és Azure lemezalapú, állandó kötet pillanatképeinek koordinálásáért.

A VMware Velero egy olyan gyakori Kubernetes biztonsági mentési megoldás, amelyet közvetlenül telepíthet és kezelhet. Vagy használhatja a AKS biztonsági mentési bővítményt a felügyelt Velero-implementáció biztosításához. Az AKS biztonsági mentési bővítmény támogatja a Kubernetes-erőforrások és az állandó kötetek biztonsági mentését, az ütemezéseket és a biztonsági mentési hatóköröket pedig tárolási konfigurációként kezelik az Azure Backupban.

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, a monitorozáshoz, a vásárláshoz és a biztonsághoz. Ezek az erőforrások tartalmazhatnak egy Azure Storage fiókot, egy Azure Backup-tárolót és -konfigurációt, valamint a megbízható hozzáférési funkciót. Ehelyett a GitOps és az állapot nélküli számítási feladatok futtatásának szándéka 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, amely magában foglalja 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 szerver SLA

Az AKS ingyenes szolgáltatásként is használható, de ez a szint nem nyújt pénzügyileg támogatott SLA-t. Az SLA beszerzéséhez ki kell választania a Standard szintet. Javasoljuk, hogy minden gyártási klaszter a Standard szintet használja. Foglalja le az ingyenes szintet a tesztelési fürtökhöz, és a Prémium szintet csak a küldetéskritikus számítási feladatokhoz. Ha Azure rendelkezésre állási zónákat használ, 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 SLA online services című témakörben talál további információt.

Kompromisszum

Az architektúra zónákban és különösen régiókban történő üzembe helyezéséhez költség és rendelkezésre állás közötti kompromisszumot jelent. Egyes replikációs funkciók, például a tárolóregisztrációs adatbázisban lévő georeplikálás, prémium termékváltozatokban érhetők el, ami drágább. Többrégiós telepítések esetén a költségek is növekednek, mivel a sávszélesség díjai éppen akkor érvényesek, amikor a forgalom a régiók között mozog.

Emellett a zónák közötti csomópontkommunikációban kis mértékű többlet hálózati késésre, a régiók közötti kommunikációban pedig nagyobb késésre számíthat. 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 foglalhatnak 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 zónahiba szimulálásához, vagy külső függőségi hiba meghívását. Az Azure Chaos Studio az Azure-ban és a fürtön előforduló különböző típusú kimaradások szimulálására is használható.

További információ: Chaos Studio.

Naplók és metrikák monitorozása és gyűjtése

Javasoljuk a Azure Monitor Kubernetes monitorozási szolgáltatásait a tárolóterhelések teljesítményének monitorozásához, mert valós időben tekintheti meg az eseményeket. Azure Monitor rögzíti a tárolónaplókat a futó podokró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 podok méretezése során a Azure Monitor 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.

Naplógyűjtés engedélyezése podokból

A ContainerLogV2 naplóséma úgy lett kialakítva, hogy a Kubernetes-podokból származó tárolónaplókat egyszerűbben rögzítse. A naplóbejegyzések egy Azure Log Analytics munkaterület ContainerLogV2 táblájába vannak összesítve.

Az AKS-fürtökben két elsődleges módszer van a podnapló-gyűjtemény konfigurálására. Mindkét módszer lehetővé teszi a beállítások testreszabását. Szűrheti a névtereket, módosíthatja a gyűjtési időközöket, engedélyezheti vagy letilthatja bizonyos funkciókat (például ContainerLogV2 vagy ContainerLogV2-HighScale), és megadhatja, hogy mely adatfolyamokat kell összegyűjteni.

• Ha több fürt központi, újrafelhasználható monitorozási konfigurációit szeretné használni, vagy a fürtkonfigurációt Azure natív erőforrásokban szeretné külsővé tenni, használja a adatgyűjtési szabályokat (DCRs). A DCR-ek olyan Azure erőforrások, amelyeket az Azure Resource Manager vezérlősíkja natív módon kezel, és Bicep fájlokba is felvehetők. A referencia-implementáció DCR-eket használ.

• A monitorozást alternatívaként ConfigMaps használatával is definiálhatja, amelyek nem bizalmas Kubernetes YAML-objektumok, és amelyek a Kubernetes API vezérlősíkján keresztül vannak konfigurálva. A fürtön futó Azure Monitor ügynök figyeli a ConfigMap-objektumokat. Előre definiált beállításokat használ annak meghatározásához, hogy mely adatokat gyűjtse össze.

Ha mindkét módszer engedélyezve van, a ConfigMap-beállítások elsőbbséget élveznek a DCR-ekkel szemben. Kerülje a tárolónapló-gyűjtés ConfigMap- és DCR-konfigurációjának keveredését, mert ez nehezen elhárítható naplózási problémákhoz vezethet.

Riasztások és Prometheus-metrikák

A kimaradások és a hibás működés jelentős kockázatokat jelentenek a számítási feladatok alkalmazásai számára, ezért elengedhetetlen az infrastruktúra állapotával és teljesítményével kapcsolatos problémák proaktív azonosítása. Amikor figyeli a környezetet, és a tanultak alapján cselekszik, csökkentheti a fennakadásokat, és javíthatja a megoldás megbízhatóságát. A fürt lehetséges meghibásodási feltételeinek előrejelzéséhez engedélyezze a a Kubernetes javasolt Prometheus riasztási szabályait.

A podokban üzemeltetett számítási feladatok többsége Prometheus-metrikákat bocsát ki. Azure Monitor integrálhatók a Prometheussal. Megtekintheti a tárolókból, podokból, csomópontokból és a fürtbő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. Így ha szervezete már használja ezeket a megoldásokat, kihasználhatja azokat.

Azure infrastruktúra és Kubernetes vezérlő sík naplói

Az AKS-sel Azure kezeli az alapvető Kubernetes-szolgáltatásokat. Azure alkalmazza az AKS vezérlősík-összetevőinek naplóit erőforrás-naplók formájában. Ezek 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. Javasoljuk, hogy a legtöbb fürtön engedélyezze a következő beállításokat:

• ClusterAutoscaler: A naplózás segítségével betekintést nyerhetünk a skálázási műveletekbe. További információért lásd: A fürt automatikus skálázási naplói és állapota.

• KubeControllerManager: Megfigyelheti a Kubernetes és a Azure vezérlősík közötti interakciót.

• kube-audit-admin: Megfigyelheti a fürtöt módosító tevékenységeket. Nincs szükség mind a kube-audit, mind a kube-audit-admin engedélyezésére, mivel a kube-audit egy szuperhalmaz, amely a nem módosító (csak olvasási) műveleteket is magában foglal.

• guard: Microsoft Entra ID és Azure RBAC-auditok rögzítése.

Hasznos lehet engedélyezni más naplókategóriákat, mint például KubeScheduler vagy kube-audit, a klaszter vagy a számítási feladatok életciklusának korai fejlesztése során. A hozzáadott fürtök automatikus skálázása, a podok elhelyezése és ütemezése, valamint 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 folyamatosan tartja a hibaelhárítási igények befejeződése után, felesleges költségek merülhetnek fel az adatok betöltésére és tárolására az Azure Monitorba.

Azure Monitor tartalmaz egy sor meglévő napló lekérdezést, amelyekből kiindulhat, de 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 query csomag használatával mentheti és újra felhasználhatja a napló lekérdezéseit. Az egyedi lekérdezések könyvtára jobb rálátást nyújt az AKS-fürtök állapotára és teljesítményére. Támogatja az Ön SLO-inak elérését.

Az AKS ajánlott eljárásainak figyelésével kapcsolatos további információkért lásd: Monitor AKS és Azure Monitor.

Hálózati metrikák

Az alapszintű fürtszintű hálózati metrikák natív platform- és Prometheus-metrikákon keresztül érhetők el. Az AKS csomóponthálózati metrikák segítségével a hálózati metrikákat a csomópont szintjén is közzéteheti a Prometheus-metrikák használatával. A legtöbb fürtnek tartalmaznia kell a hálózati megfigyelhetőséget, hogy további hálózati hibaelhárítási képességeket biztosítson, és hogy észlelje a nem várt hálózati használatot vagy problémákat a csomópont szintjén.

A referencia-implementáció Azure Monitor használ, amely szintén gyűjt néhány hálózattal kapcsolatos metrikát. A referencia-implementáció tiltja egyes hálózati metrikák közvetlen gyűjtését az Azure Monitortól, és ehelyett a hálózati megfigyelhetőségi adatokat egy Azure Monitor munkaterületen managed Prometheus-t használva gyűjti össze.

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 ezeket a részletes metrikákat az Advanced Container Networking Services funkció használatával érheted el. A legtöbb számítási feladathoz nincs szükség ilyen mélységű hálózati megfigyelhetőségre. Ne engedélyezze a fejlett hálózati megfigyelhetőséget, hacsak a podok nem igényelnek nagymértékben optimalizált hálózatot, és nem követelik meg a csomagszintű érzékenységet.

Költségoptimalizálás naplózáshoz

A referencia-implementáció úgy konfigurálja a ContainerLogV2 táblát, hogy kiindulási pontként használja az Alaptervet. Microsoft Defender for Containers és a referencia-implementációhoz létrehozott riasztások nem használják fel ezt a táblázatot, így az Alapszintű csomag valószínűleg költséghatékony, mert csökkenti az adatbetöltési költségeket.

A naplók mennyiségének és lekérdezési követelményeinek fejlődésével válassza ki az igényeinek leginkább megfelelő táblázattervet. Ha a megoldás olvasásigényessé válik, ahol a lekérdezések gyakran ellenőrzik a táblaadatokat, az alapértelmezett Elemzési csomag megfelelőbb lehet. Az Analytics-csomag kiküszöböli a lekérdezési díjakat, ami olyan helyzetekre optimalizál, amikor a lekérdezési tevékenység meghaladja a betöltési költségeket. Ha figyeli a használati mintákat, és szükség szerint módosítja a táblázatterveket, egyensúlyt teremthet a monitorozási megoldás költségei és funkciói között.

További információ: Az Log Analytics munkaterület adathasználatán alapuló táblaterv kijelölése.

Ö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.

Note

Az AKS rendelkezik egy automatikus csomópontjavítási funkcióval amely beépített önjavítást biztosít az infrastruktúra-csomópontok számá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éteg kezelését kell elvégezni.

• A Kubernetes verziója (például a Kubernetes 1.32.3–1.32.7 vagy a Kubernetes 1.32.7–1.33.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 Windows Update vagy apt. Az operációs rendszer szállítója közvetlenül biztosítja ezeket a frissítéseket, és ezek nincsenek tesztelve a fürt Kubernetes-verziójával. 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 minden AKS-fürt, csomópontkészlet vagy csomópont milyen gyakran frissül (a frissítési ü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 ahogyan a fürtön futó számítási feladatnak biztonságos ügyintézési gyakorlatra van szüksége, a fürtök frissítése is igényli ezt.

A javítással és frissítéssel kapcsolatos átfogó perspektíváért tekintse meg a AKS javítással és frissítéssel kapcsolatos útmutatóját a AKS 2. napi ü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 változtathatatlan 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 kép frissítés értékét none, és a cluster automatikus frissítés értékét 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, a következő lépéseket kell végrehajtania:

1. Tesztelje a frissítést egy előkészületi környezetben, és értékelje annak kompatibilitását egy új fürtön.

2. Telepítsen egy éles replikabélyeget, amely tartalmazza a frissített AKS-verziót és a csomópontkészlet virtuális merevlemezeit.

3. Amikor az új termelési fürt készen áll, kiürítse a régi fürtöt, és végül szerelje le azt.

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

Helyszíni frissítések

Azok a számítási feladatok, amelyek nem változtathatatlan infrastruktúraként működtetik az AKS-fürtöket, rendszeresen frissíteniük kell a futó fürtöket mindhárom réteg frissítéséhez. 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ás 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 pod-megszakítási költségvetéseket, hogy az alkalmazás stabil maradjon a forgó frissítések alatt. 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 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 Azure kvótának és IP-címtérnek elérhetőnek kell lennie az új csomópontokhoz. A túlterhelési érték 33% 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. Emellett 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 futtathat 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. Microsoft teszteli a frissítéseket az AKS-verzión. Windows csomópontok esetében a frissítések havonta körülbelül egyszer történnek. Linux-csomópontok esetén a frissítések körülbelül hetente 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 a frissítések időben történő alkalmazását bármilyen csomópontképet használó operációs rendszer esetén.

• 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ő-verziószámait a AKS kiadáskövető használatával követheti nyomon.

Ha a fürt biztonsági követelményei szigorúbb javítási ütemtervet igényelnek, és a fürt meg tudja engedni magának a lehetséges megszakításokat, akkor használja inkább az SecurityPatch upgrade csatornát. 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 Microsoft fontosnak tart ahhoz, hogy a következő ütemezett csomópontrendszerkép-frissítés előtt megjelenjenek. A SecurityPatch csatorna használatakor a NodeImage csatorna által kapott frissítéseket is megkapja. A SecurityPatch csatorna opció továbbra is tiszteletben tartja a karbantartási időablakokat, ezért győződjön meg arról, hogy a karbantartási időablakban rendszeres szünetek vannak (például naponta vagy két naponta), hogy támogassa ezeket a váratlan biztonsági frissítéseket.

A legtöbb helyszíni frissítést használó fürtnek kerülnie kell a csomópont képfrissítési NoneUnmanaged csatornaopciókat.

A fürt helyben történő 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 naprakész maradj a Kubernetes-frissítésekkel kapcsolatban. A két legutóbbi verzióban (N-2) 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 megfelelő óvatossággal és alapossággal képesnek kell lennie a helyben történő AKS-verziófrissítések végrehajtására. A helyben történő AKS-verziófrissítések kockázatát többnyire csökkenteni lehet a megfelelő előzetes teszteléssel, a kvótaérvényesítéssel és a pod-kimaradási költségvetés beállításával. A helyszíni frissítések azonban váratlan viselkedést eredményezhetnek. Ha a helyben történő frissítések túl kockázatosnak minősülnek a számítási feladatokhoz, javasoljuk, hogy a fennmaradó javaslatok követése helyett az AKS-fürtök blue-green üzembe helyezési megközelítését használja.

Javasoljuk, hogy a Kubernetes-fürt első üzembe helyezésekor kerülje a fürt automatikus frissítése funkciót. Használjon kézi 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 bekerülnének az éles környezetbe. 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 egy 'naprakész' gondolkodásmódot követni, mint egy hosszú távú támogatás megközelítést.

Warning

Nem javasoljuk egy éles AKS-fürt automatikus javítását vagy frissítését, még alverziófrissítések esetén sem, hacsak először nem tesztelte ezeket a frissítéseket az alacsonyabb környezetekben. További információkért tekintse meg az alábbiakat: A Kubernetes legújabb verziójára történő frissítés és AKS-fürt frissítése.

Értesítést kaphat, ha új AKS-verzió érhető el a fürthöz az Azure Event Grid AKS rendszerének használatával. A referencia-implementáció üzembe helyezi ezt az Event Grid-rendszert, hogy előfizethesse a Microsoft.ContainerService.NewKubernetesVersionAvailable eseményre az eseménystream értesítési megoldásából. Tekintse át a AKS kibocsátási megjegyzéseit a kompatibilitási problémák, a viselkedésváltozások vagy a funkciók elavulása esetén.

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. Éles rendszerek esetében ritkán haladunk túl patch. Ha automatikusan frissíti az AKS-verziót, ellenőrizze az infrastruktúra AKS-verzióbeállítását kódként (IaC), hogy a kettő ne ússzon ki a szinkronizálásból. Konfigurálja a tervezett karbantartási időszakot az automatikus frissítési művelet támogatásához.

Biztonsági monitorozás

A tárolóinfrastruktúra figyelése az aktív fenyegetések és a potenciális biztonsági kockázatok szempontjából is. További információt a következő források tartalmaznak:

• Microsoft Defender for Containers azonosítja és orvosolja a Defender for Cloud tárolóképekre vonatkozó javaslatait.
• A tárolókhoz készült Defender rendszeresen vizsgálja a konténerképeket biztonsági rések után.
• Defender a tárolók esetében is létrehoz valós idejű biztonsági riasztásokat a gyanús tevékenységek esetén.
• Az AKS-ben lévő alkalmazások és fürtök biztonsági fogalmai részletes információk arról, hogy a tárolóbiztonság hogyan védi a teljes teljes folyamatot a buildeléstől az AKS-ben futó alkalmazásterhelésekig.

Klaszter- és számítási feladat operációk

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

Fürt rendszerindítása

A fürt beállítása után a rendszer már működőképes, de előfordulhat, hogy a számítási feladatok telepítése előtt további lépések végrehajtása szükséges lehet. Az előkészítési folyamatot, amellyel a fürtöt beállítjuk, bootstrappingnek nevezzük. A rendszerindítás gyakran magában foglalja az előfeltételként szolgáló rendszerképek fürtcsomópontokra való üzembe helyezését, névterek létrehozását és a szervezet használati helyzetének követelményeinek megfelelő egyéb feladatok elvégzését.

Az újonnan beállított fürtről egy megfelelően konfiguráltra való áttérés felgyorsításához meg kell határoznia az egyedi rendszerindítási folyamatot, és előre el kell készítenie a megfelelő objektumokat. Ha például olyan szolgáltatáshálót használ, mint a Linkerd vagy a Consul Connect, általában az alkalmazás számítási feladatainak ütemezése előtt helyezi üzembe a hálót. A fürt beállítása előtt ellenőriznie kell, hogy a szolgáltatásháló lemezképei egy korábban létrehozott tárolóregisztrációs adatbázisban találhatók-e. Ez az ellenőrzés segít megelőzni az üzembe helyezési késéseket vagy hibákat.

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

• GitOps Flux v2 klaszter kiterjesztés
• Pipelines
• Önkonfigurálás Flux vagy Argo CD-vel, például

Note

Ezen módszerek bármelyike bármilyen fürttopológiával működik, de javasoljuk a GitOps Flux v2 fürtbővítményt a flották számára az egységesség és a nagyobb léptékű könnyebb szabályozás miatt. Ha csak néhány klasztert futtat, a GitOps túl összetett lehet. Ehelyett úgy dönthet, hogy integrálja a folyamatot egy vagy több üzembe helyezési folyamatba, hogy biztosítsa a rendszerindítás megtörténtét. Használja a szervezet és a csapat célkitűzéseinek leginkább megfelelő módszert.

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 környezetet szilárd menedzsment alapokkal teremti meg a jövőben, és támogatja a bootstrapping erőforrássablonokként való alkalmazását is az IaC-stratégia összehangolása érdekében.

Végül, ha a GitOps Flux v2 fürtbővítményt használja, a kubectl nem szükséges a rendszerindítási folyamat egyik szakaszához sem. A kubectl-alapú hozzáférés lefoglalható vészhelyzeti 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 a kubectl használata nélkül is elvégezhet minden normál konfigurációs tevékenységet.

Munkafelelősségek 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. Állítson be virtuális hálózatokat a központhoz és küllőkhöz, valamint az alhálózatokhoz 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, a bejövő erőforrásokhoz és a privát AKS API-kiszolgálóhoz. Helyezzen üzembe egy alhálózatot Azure Firewall a központban.

Egy másik feladat az alapvető munkaterhelés integrálása a Microsoft Entra ID-vel.

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. A referencia-implementáció Bicep használ, de választhat a Terraform vagy Azure Resource Manager sablonok (ARM-sablonok) helyett.

Mindenképpen állítson be erőforrásokat a szabályozási szabályzatok szerint. 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. A Azure Policy használatával is kikényszerítheti a szervezet szabályzatait ezekre a döntésekre.

Ha parancssorozatot kell írnia, használja a Azure CLI. Ezek a parancsok számos Azure szolgáltatást fednek le, és szkriptekkel automatizálhatók. Windows és Linux támogatja a Azure CLI. Egy másik platformfüggetlen lehetőség a 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.

Munka-terhelés CI/CD

A munkafolyamatokhoz és üzembe helyezéshez használt folyamatoknak képeseknek kell lenniük az alkalmazások folyamatos létrehozására és üzembe helyezésére. A frissítéseknek biztonságosan és gyorsan kell üzembe helyezniük, és vissza kell tudniuk állni, 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 munkaterhelési konténerképek változtatásait automatikusan üzembe helyezheti a klaszterben.

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

Klaszter CI/CD

Diagram, amely a CI/CD számítási feladatot jeleníti meg.

Az ábrán a CI/CD munkafolyamat látható balról jobbra. A bal oldalon a kódként használt infrastruktúra ikon a forrásvezérlőben tárolt deklaratív konfigurációt jelöli. Egy vízszintes nyíl, "Deploy" felirattal, az infrastruktúra mint kód felől egy "GitOps" felirattal ellátott központi mezőre mutat. Ez a mező Azure Pipelines, GitHub Actions és Jenkins-folyamatokat tartalmaz. A GitOps-mezőből a Szinkronizálás feliratú nyíl egy AKS-ikonra mutat.

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 változá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 telepítésének megkezdése. A GitOps-megközelítés azért hasznos, mert lehetővé teszi, hogy az operátorok deklaratívan megadják a rendszerindítási folyamatot az IaC-stratégia részeként, és automatikusan lássák a konfiguráció visszatükröződését a klaszterben.

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ökprogram a Flux, amely a fürtben lévő egy vagy több operátort használja a Kubernetes környezetén belüli üzembe helyezések aktiválásához. A Flux a következő feladatokat végzi el:

• Az összes konfigurált adattár monitorozása
• Új konfigurációmódosításokat észlel
• Központi telepítések aktiválása
• Frissíti a kívánt futó konfigurációt a módosítások alapján

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

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

A diagram a GitOps-munkafolyamatot négy számozott lépéssel mutatja be balról jobbra. A bal szélen egy laptopot tartalmazó fejlesztői ikon jelenik meg 1. lépésként, ahol a felhasználó az IaC-módosításokat egy Git-adattárba küldi. A 2. lépés a Git-adattárat mutatja be, amely egy git clone --mirror címkével ellátott nyíllal csatlakozik a Flux-ikonhoz az AKS-fürt határán belül. A 3. lépésben egy kubectl feliratú nyíl látható, amely a fürtön belül a Flux ikonról a Kubernetes API-kiszolgáló ikonra mutat. A 4. lépés egy piros kört jelenít meg, amelynek átlós vonala van a fejlesztő és a Kubernetes API-kiszolgáló között egy keresztbe helyezett kubectl címkével.

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-nek írásvédett hozzáférése van a Git-adattárhoz, hogy meggyőződjön 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 access 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.

Terhelések és klaszterek üzembe helyezési stratégiái

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

A következő szakasz folytatása előtt minden fázisban 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 éles használathoz hasonló eljárást kell követnie ugyanazzal a GitHub Actions és Flux operátorok használatával.

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. 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 a Well-Architected Framework for AKS című cikkben ismertetett javaslatokat. Az általános számítási feladatokra vonatkozó javaslatokért tekintse meg a Design költségoptimalizálási ellenőrzőlistát.

Az alaparchitektúrában használt összetevők költségbecslését a Azure díjszabási kalkulátorban találja. Módosítsa a becslést úgy, hogy tartalmazza a használati esethez szükséges összetevőket.

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

Provision

• Ismerje meg, hogy honnan származnak a költségek. Minimális költségek társulnak az AKS-hez a Kubernetes-fürt üzembe helyezésével, kezelésével és üzemeltetésével kapcsolatban. A költségeket a fürt által felhasznált virtuális gép példányok, tárhely, naplóadatok és hálózati erőforrások befolyásolják. Érdemes lehet olcsóbb virtuális gépeket választani a rendszercsomópont-készletekhez. A Ddv5 sorozat a rendszercsomópontkészlet tipikus virtuálisgép-típusa, és a referencia-implementáció a Standard_D2d_v5 termékváltozatot használja.

• Ne használja ugyanazt a konfigurációt fejlesztői/tesztelési és éles környezetekhez. Az éles munkaterhelések extra követelményeket támasztanak a nagy rendelkezésre állás érdekében, és általában drágábbak. Ez a konfiguráció nem szükséges a fejlesztői/tesztelési környezetben.

• Adjon hozzá rendelkezésre állási SLA-t az éles környezetben futó feladatokhoz. Vannak azonban megtakarítások a fejlesztési és tesztelési vagy kísérleti munkaterhelésekhez tervezett fürtök esetében, ahol a rendelkezésre állás nem garantált. Az SLO például elegendő lehet. Emellett, ha a számítási feladat támogatja, fontolja meg a dedikált spot csomópontkészletek használatát, amelyek spot virtuális gépeket futtatnak.

  Nem gyártási feladatokhoz, amelyek részét képezi az AKS számítási feladatarchitektúra, valamint az Azure SQL Database vagy az Azure App Service, értékelje ki, hogy jogosult-e az Azure Dev/Test előfizetések használatára és a szolgáltatások kedvezményes igénybevételére.

• Hozzon létre egy fürtöt a csomópontok minimális számával, és kapcsolja be a fürt automatikus skálázóját, hogy monitorozhassa és méretezési döntéseket hozhasson, ahelyett, hogy a skálázási igények kielégítésére az elejétől túlméretezett fürttel indulna.

• Á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 a csomópontok teljes kapacitását használhassa.

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

• Kötelezze el magát egy vagy hároméves Azure fenntartott virtuálisgép-példányokra a csomópontköltségek csökkentése érdekében, ha a számítási feladatnak hosszú ideig kell léteznie. További információ: Költségmegtakarítás az Azure fenntartott virtuális gé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 meg van osztva a csapatok között, minden fogyasztó számára díjvisszatérítési jelentéseket kell készíteni a megosztott felhőszolgáltatások mért költségeinek azonosításához. További információért lásd: Állítsa be a tünetet, címkét vagy taget egy csomópontkészlethez.

• 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ó: Bandwidth díjszabás.

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

Monitor

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

• Azure Advisor
• Költségkezelés

Valós időben vagy rendszeres ütemezéssel figyelheti a költségeket, hogy a hónap vége előtt, amikor már ki vannak számítva a költségek, megtehesse a szükséges lépéseket. A havi trendek folyamatos figyelemmel kísérése érdekében maradjon a költségvetésen belül.

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ámokat Azure Monitor metrikákban tekintheti meg.

Optimize

Kövesse Azure Advisor javaslatait. Az optimalizálás egyéb módjai:

• 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.

  Important

  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ópontszámának) gyors vagy gyakori módosítása a költségek szabályozásához nem szándékos vagy kontraproduktív eredményekhez vezethet. 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 fölösleges idejének újraszámítása a fürt automatikus skálázási beállításainak frissítésekor történik.

• 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 jogosultsági szintűvé alakítását a teljesítménymetrikák időbeli elemzésével.

• Ha a számítási feladat támogatja, a felhasználói csomópontkészleteket nulla csomópontra skálázhatja ha nem várható, hogy futjanak. Ha a fürtben nem futnak ütemezett 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 információ: AKS díjszabás.

Következő lépések

• AKS ütemterve a GitHub

Kapcsolódó erőforrások

• Az AKS mikroszolgáltatás-architektúrája
• Microservices architektúra az AKS-en
• Használja az Azure Firewall szolgáltatást az AKS-fürt védelméhez
• GitOps for AKS
• Adatstreamelés az AKS