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.

Tip

Ez a cikk az AKS-fürtök átfogó tervezési szempontjait ismerteti. Az AKS Automatic számos tervezési döntést implementál, hogy csökkentse az értékelendő szempontok számát, és optimalizálja a gyakori használati eseteket. Az AKS Automatic például egy felügyelt rendszercsomópontkészletet helyez üzembe és üzemeltet, így a jelen cikkben szereplő rendszercsomópont-készlet méretezési, elkülönítési és frissítési döntései nem vonatkoznak erre a platformra.

Még akkor is, ha a számítási feladat egy AKS Automatikus környezetben lesz üzemeltetve, a saját felügyeletű AKS-fürt alapjainak ismerete segíthet a megfelelő döntések meghozatalában a számítási feladat módosításakor.

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
Alkalmazás útválasztása

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íl az AKS-fürtről a Azure Monitor munkaterületszakaszra mutat, 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ügyeleti műveletekhez 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.

Belső terheléselosztó IP-címeinek alhálózata

Ez az alhálózat biztosítja a belső terheléselosztó előtérbeli IP-címterét. Az Application Gateway forgalmat küld a hozzárendelt belső terheléselosztó IP-címére, a terheléselosztó pedig a fürt bármely csomópontja felé osztja el a forgalmat.

A fogadó csomópont kube-proxyügynöke továbbítja a csomagot a rendszercsomópont-készlet átjáróproxy-podjának, ami további hálózati ugrást is jelenthet. A proxy leállítja a Transport Layer Security (TLS) protokollt, és HTTP-n keresztül továbbítja a kérelmeket a számítási feladatok podjaira.

Ha dedikált alhálózatot használ az előtérbeli terheléselosztó IP-címeihez, olyan hálózati biztonsági csoport (NSG) szabályokat alkalmazhat, amelyek a terheléselosztó felé irányuló bejövő forgalmat a csomópont alhálózatának befolyásolása nélkül hatókörzik. További információ: A belső load balancer AKS.

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

Ez az architektúra két csomópontkészletet használ, amelyek külön csomópontcsoportok. A rendszercsomópont-készlet az alapvető fürtszolgáltatásokat futtató podokat üzemelteti, beleértve az átjáróproxyt is, amely a forgalmat a számítási feladathoz irányítja. A felhasználói csomópontkészlet futtatja a számítási feladatot.

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, és ugyanazon a virtuális hálózaton tartja a fürthöz tartozó erőforrásokat. Az alhálózat szintjén részletes biztonsági szabályokat is alkalmazhat az 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ó, valamint a fürt belső és külső ügyfelei 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özponti virtuális hálózat Azure Firewall, Azure Bastion és átjáróalhálózattal rendelkezik. A küllős virtuális hálózat alhálózatokkal rendelkezik az Application Gatewayhez, a bejövő forgalomhoz, a csomópontokhoz, a privát végpontokhoz és egy privát fürthöz. A nyilak a küllős hálózatok és a központi hálózat közötti társviszony-létesítési kapcsolatokat mutatják.

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

Ez a referenciaarchitektúra a következő hálózati megközelítéseket használja, amelyek mindegyike külön 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 Azure tárolóhálózati felület (CNI) átfedése, amellyel a fürt ip-címeket rendel a podokhoz a Azure virtuális hálózattól különálló címtérből.

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 alhálózatot eredményez. Az átjáró topológiája azért is kibővülhet, mert minden átjáró-erőforrás saját átjáróproxy-üzembe helyezést és terheléselosztó előtérbeli IP-címét állítja elő. Ennek megfelelően tervezze meg az alhálózat címterét.

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 az Osztály nélküli Inter-Domain Útválasztás (CIDR) tartományhoz /16 címteret használ, a fürt 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, csak azokat, amelyek jelentős értéket adnak 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.

Érdemes lehet kiértékelni néhány más előzetes verziójú funkciót vagy AKS-bővítményt 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. Minden nem Microsoft bővítményt telepítenie és karbantartania kell, amely 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 fürt tartalmazhatja a munkaterhelést és számos más rendszerképet, például saját felügyeletű átjáró-infrastruktúrát vagy egy olyan segédtárolót, amely szinkronizálja a TLS-tanúsítványokat a Key Vaultból. E képfájlok némelyike nyilvános regiszterekben is megtalálható lehet, de bevált gyakorlat, hogy azokat átvizsgálva, auditálva és egy dedikált privát regiszterben, például az Azure Container Registryben tárolja. 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. A referencia-implementációban a fürt csak a fürttel üzembe helyező dedikált Azure Container Registry példányról kér le 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. 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.

• A fürt kapacitásának tervezésekor tegyük fel, hogy a számítási feladat az egyes csomópontok legfeljebb 80% használ fel. 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. A referencia-implementáció Azure Linuxot használ, amely egy egyszerű, edzett Linux-disztribúció, amely Azure 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éssel vagy a futtatókörnyezettel kapcsolatos 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 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 külső és a külső 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ülső hozzáférés: Adjon meg identitásokat a Kubernetes-fürthöz való hozzáféréssel. 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. Szolgáltatásnevek esetén manuálisan vagy programozott módon kell kezelnie és elforgatnia a titkos kulcsokat. Felügyelt identitások esetén Microsoft Entra ID kezeli és végrehajtja a titkos kódok hitelesítését és időben történő rotálását.

Javasoljuk, hogy engedélyezze és használja 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 Registry használatával hitelesít. Egyes bővítmények a felügyelt identitás használatával is támogatják a hitelesítést.

Felügyelt identitást kell használnia, ha a fürtnek lemezképeket kell lekérnie egy tárolóregisztrációs adatbázisból. Ehhez a művelethez a fürtnek le kell szereznie a beállításjegyzék hitelesítő adatait, amelyet a fürt kubelet által felügyelt identitásának AcrPull a beállításjegyzékhez való hozzáférésével engedélyezhet. Ha nem használ felügyelt identitást, ezeket az adatokat egy Kubernetes-titkos kódban tárolhatja, és imagePullSecrets lekérheti. Ezt a megközelítést nem javasoljuk, mert biztonsági összetettségeket vezet be, például előre ismernie kell a titkos kódot, és a DevOps-folyamatban kell tárolnia. 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 Azure olyan erőforrásokhoz fér hozzá, amelyeket Microsoft Entra ID biztonságossá, és a fürt felügyelt identitásokat támogató műveleteket hajt végre. A fürt által végzett műveletektől függően Azure szerepköralapú hozzáférés-vezérlési (Azure RBAC-) szerepköröket és engedélyeket rendelhet a fürt felügyelt identitásaihoz. A fürt hitelesíti magát a Microsoft Entra ID, és a hozzá rendelt szerepkörök alapján engedélyezi vagy megtagadja a hozzáférést. A referencia-implementáció alábbi példái Azure a fürthöz rendelt beépített szerepköröket mutatják be:

• 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 rendszer által hozzárendelt identitása együttműködhet az átjáróproxyt és az AKS privát API-kiszolgálót kezelő belső terheléselosztó dedikált alhálózatával.

• A saját 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 privát DNS-zóna használatával tartják távol a DNS-rekordokat a nyilvános internetről, de továbbra is létrehozhatnak nyilvános DNS-címmel rendelkező privát AKS-fürtöt. Javasoljuk, hogy kifejezetten tiltsa le ezt a funkciót enablePrivateClusterPublicFQDN úgy, hogy false megakadályozza 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.

Két AKS-bővítmény további felügyelt identitásokat épít ki, amelyek szerepkör-hozzárendeléseket igényelnek. A Titkos kulcstár CSI-illesztőprogram bővítmény identitása lekéri a TLS-tanúsítványokat Key Vault. Az alkalmazás-útválasztási bővítmény identitása kezeli a DNS-rekordokat és az átjáró egyeztetését.

Adjon hozzáférést a két identitásnak az általuk használt erőforrásokhoz:

• A Titkos kulcstár csi-illesztőprogram felügyelt identitás bővítményének szüksége van a key vault Key Vault tanúsítványfelhasználói szerepkörére, hogy az illesztőprogram le tudja kérni a TLS-tanúsítványokat.

  Note

  Alternatív megoldásként lecserélheti a CSI Driver bővítmény felügyelt identitását Microsoft Entra számítási feladat identitására Key Vault hozzáféréshez. Számítási feladat identitásának használatakor összevont hitelesítő adatokkal köt egy felhasználó által hozzárendelt felügyelt identitást egy Kubernetes ServiceAccounthoz, és hivatkozik a ServiceAccountra az átjáró figyelőjének TLS-beállításai között. Az alkalmazás-útválasztási bővítmény ezután automatikusan létrehozza a SecretProviderClass szolgáltatást.

  Általában vagy a bővítmény felügyelt identitását, vagy a Workload Identityt választja a Key Vaulthoz a CSI-illesztőprogramon keresztüli hozzáféréshez. A Számítási feladatok identitása névtér hatókörű identitáselkülönítést biztosít, és csökkenti a manuális erőforrás-kezelést a hozzáadott identitások összevont hitelesítő adatokon keresztüli megkeményedésének költségén.

• Az alkalmazás-útválasztási bővítmény felügyelt identitásának szüksége van a Key Vault Titkos kulcsok felhasználója és Key Vault Olvasó szerepkörökre a key vault. Ahhoz, hogy a beépített DNS-összetevő összeegyeztethesse az átjáró erőforrásait, ehhez az identitáshoz szükség van a saját DNS zóna közreműködői szerepkörére is a bejövő private DNS zónában.

  Note

  A bővítményben üzembe helyezett beépített DNS-összetevő nem egyezteti automatikusan a DNS-rekordokat. Átjáró API-rekordjaihoz használja a Számítási feladatok identitása megközelítést.

További információ: Azure DNS és TLS konfigurálása az alkalmazás-útválasztási átjáró API-implementációval.

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.

A referencia-implementációban a helyi fürtfiókok hozzáférése kifejezetten tilos, amikor a rendszer üzembe helyezi a fürtöt.

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. A számítási feladat például fájlokat tárolhat Azure Storage. Amikor a podnak hozzá kell férnie ezekhez a fájlokhoz, az Azure felügyelt identitásként hitelesíti magát az erőforráson.

A referencia-implementációban az AKS Microsoft Entra Számítási feladat ID biztosítja a podok felügyelt identitásait. Ez a megközelítés integrálható a Kubernetes natív képességeivel a külső identitásszolgáltatókkal való összevonáshoz. 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 két hálózati modellben biztosít CNI-beépülő modulokat: á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ózaton 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 az implementáció Azure CNI Overlay-t használ, egy átfedéses hálózati beépülő modult, amely csak csomópontokhoz rendeli a virtuális hálózati IP-címeket, és pod IP-címeket rendel 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.

Alkalmazás útválasztása

Ez az architektúra a Kubernetes Gateway API alkalmazás-útválasztási bővítményét használja. Az alkalmazásútválasztási bővítmény egy olyan AKS-fürtkonfiguráció, amely előírja, hogy a fürt felügyelt átjáró-infrastruktúrát tartalmazzon. Az Átjáró API a Kubernetes egyéni erőforrásdefinícióinak (CRD-k) készlete, beleértve a GatewayClass, Gateway, HTTPRouteés másokat is. A Kubernetes-közösség az átjáró API-t jelölte ki az előző bejövő API utódjaként. Az Átjáró API szabványosított, szerepkör-orientált és bővíthető keretrendszert biztosít a forgalomkezeléshez.

Az Átjáró API-összetevők az alábbi életciklus-szakaszokban telepíthetők:

• Klaszter tervezése. Az alkalmazáscsapat dönti el, hogy melyik átjáróvezérlő kezelje a bejövő forgalmat, és hogyan kezelje a vezérlő életciklusát. Az átjáróvezérlők általában összecsomagolják az adatsík-proxyikat, így ez a döntés azt is meghatározza, hogy melyik proxy kezeli a forgalmi útvonalat. Ez az architektúra lehetővé teszi a felügyelt Gateway API CRD-k használatát. Úgy konfigurálja a bővítményt, hogy a felügyelt Istio-t használja átjáróvezérlőként, amely az Envoyval párosítja az átjáróproxyt. Bár az Istio szolgáltatáshálóként is használható, ez az architektúra csak az Istio-t használja átjáróvezérlőként, és nem engedélyezi a szolgáltatásháló képességeit.

  Ha a csapat más implementációt igényel, más átjáró API-vezérlőket is használhat, például NGINX-átjáró Fabric, Envoy Gateway és Traefik. Ezeknek a vezérlőknek az önkezeléséhez jegyzékek, affinitás-ellenesség, csomópontelhelyezés, mintavételek, RBAC-hatókörkezelés, méretezési szabályzatok, forrás IP-korlátozások és verzióéletciklus szükséges. Cserébe a csapatok teljes körű irányítást kapnak a proxy viselkedése, a fürtfrissítések és a nem konfigurált konfigurációktól független verzió-rögzítés felett.

• Fürtkiépítés. Ebben a szakaszban nem születnek tervezési döntések. Az AKS telepíti az Átjáró API CRD-jait, az Istio átjáróvezérlő podjait a aks-istio-system névtérben és a approuting-istio GatewayClass-t. Ebben a szakaszban nincsenek az átjáróproxyhoz tartozó adatsík-podok.

• Klaszter inicializálása. A számítási feladatokért felelős csapat meghatározza, hogy az átjáróproxy belső vagy külső terheléselosztón keresztül van-e közzétéve, melyik alhálózat üzemelteti a terheléselosztó előtérbeli IP-címét, és melyik névtérben fut az átjáróproxy. Ebben az architektúrában az átjáróproxy egy belső terheléselosztón jelenik meg. A terheléselosztó IP-címeinek dedikált alhálózata van, és az átjáróproxy a a0008 számítási feladat névterében van üzembe helyezve.

  A(z) approuting-istio GatewayClass-ra hivatkozó Gateway-erőforrás ezeket a döntéseket fejezi ki. Az átjáróvezérlő egyezteti az erőforrást az envoy gateway proxy üzembe helyezéseivel, a LoadBalancer szolgáltatással, a HorizontalPodAutoscalerrel és a PodDisruptionBudgettal ugyanabban a névtérben, mint az átjáróerőforrás.

  Ha egy privát DNS-zóna csatlakozik a bővítményhez, a bővítmény DNS-összetevője kezelheti a DNS A rekordokat, így nem kell statikus rekordokat fenntartania az infrastruktúrában kódsablonként (IaC). A kezdeti rendszerindítás a A klasztertitkok elérése című részben leírt, a TLS-tanúsítványok szinkronizálásához szükséges erőforrásokat is üzembe helyezi.

  Note

  A bővítménnyel telepített beépített DNS-összetevő nem szinkronizálja automatikusan a DNS-rekordokat a Gateway API-erőforrások használatakor. A privát DNS-rekordok automatikus egyeztetésének engedélyezéséhez helyezzen üzembe egy ClusterExternalDNS vagy ExternalDNS egyéni erőforrást. Az alkalmazás-útválasztási operátor összetevő ezután üzembe helyez egy felügyelt external-dns példányt, amely figyeli az átjáró- és HTTPRoute-erőforrásokat, és közzéteszi az A rekordokat a csatolt DNS-zónában.

  Mivel a DNS-zónába való íráshoz RBAC-engedélyekre van szükség, ehhez az integrációhoz Microsoft Entra számítási feladat identitására van szükség, beleértve a felhasználó által hozzárendelt felügyelt identitást a célzóna DNS-zóna-közreműködőjével, a fürt OpenID Connect (OIDC) kiállítójában megbízható összevont identitási hitelesítő adatokat és egy dedikált Kubernetes ServiceAccountot. Értékelje ki a további identitásinfrastruktúra-követelményeket a biztonsági és üzemeltetési igényeknek megfelelően.

• Munkaterhelés telepítése. Az alkalmazás csapata határozza meg, hogy mely gazdagépnevek, útvonalak és háttérrendszerek fogadják a forgalmat. Az átjáróhoz kötődő HTTPRoute-erőforrások kifejezik ezeket az útválasztási döntéseket. Az átjáróvezérlő továbbítja a deklarált útválasztási viselkedést az Envoy-podoknak.

• Folyamatos karbantartás: A bővítmény az Istio-átjáróvezérlő verzióját az AKS-fürt verziójához kapcsolja, így a frissítések a fürtfrissítések mellett történnek ahelyett, hogy független életciklus-kezelést igényelnek. Ez a bővítmény kizárólag az Átjáróproxy-felügyelethez használja az Istio-t. Nem engedélyezi az oldalkocsi-injektálást vagy a teljes Istio szolgáltatáshálót, amely egy külön bővítmény.

Note

Önkezelést akkor válasszon, ha a számítási feladat olyan képességeket igényel, amelyeket a bővítmény még nem támogat, például a TLSRoute for Server Name Indication (SNI) átengedését, az egyéni Lua- vagy Wasm-beépülő modulokon keresztüli speciális forgalomátalakításokat, vagy ha a megfelelőség egy adott proxyterméket ír elő. Akkor is válassza az önkezelést, ha a proxyt függetlenítenie kell a fürtfrissítésektől, vagy ha a fürt már használja az Istio service mesh bővítményt, mert a két bővítmény nem létezhet együtt.

Átjáró- és HTTPRoute-erőforrások alkalmazása

Ez az architektúra a Kubernetes Gateway API alkalmazás-útválasztási bővítményét használja a bejövő forgalom kezelésére. Ez a szakasz az előző szakaszban ismertetett fürtindítási és számítási feladatok üzembe helyezési fázisait ismerteti. Ezen a ponton az átjáróvezérlő fut, és várja az átjáró API-erőforrások egyeztetését.

Az Átjáró API egy szállítósemleges szabvány, amely a TLS-szabályzatot, a fejlécalapú útválasztást és a forgalomfelosztást natív API-mezőkként fejezi ki a implementációspecifikus széljegyzetek helyett. Mivel az útválasztási konfiguráció nem függ egy adott proxytechnológiától, később anélkül módosíthatja a mögöttes implementációt, hogy újraírta volna. Az alkalmazás-útválasztási bővítmény diktálja az átjáróvezérlőt és a proxy életciklusát, ami szükségtelenné teszi a frissítések, a biztonsági javítások, a skálázási konfiguráció és az RBAC-hatókörkezelés kezelését.

Az Átjáró API két olyan erőforrásra választja el a bejövő forgalmat, amelyek egymástól függetlenül változnak:

• Az átjáró-erőforrás deklarálja a hálózati felületet, beleértve a közzéteendő portokat és protokollokat, a TLS-tanúsítványokat és a belső terheléselosztó alhálózatát. Ez az erőforrás ritkán változik, és a hozzá tartozó összes útvonalra hatással van.

• A HTTPRoute-erőforrás deklarálja az útválasztási logikát, vagy azt, hogy mely gazdagépeket, útvonalakat és fejléceket rendeli hozzá a háttérszolgáltatásokhoz. Ez az erőforrás minden üzembe helyezéskor megváltozik, és az egyes szolgáltatásokra terjed ki.

Ez az architektúra csökkenti annak kockázatát, hogy egy útválasztási változás megzavarja a hálózati konfigurációt, vagy fordítva, mivel minden erőforrás eltérő változási ütemű és robbanási sugarú. Emellett több függőséget is eltávolít.

• Az útválasztási konfiguráció nincs egy adott proxytechnológiához kötve.
• A proxyverzió az AKS-fürt verziójával együtt mozog ahelyett, hogy független nyomon követést igényel.
• Minden átjáró-erőforrás saját proxytelepítést kap ahelyett, hogy egyetlen vezérlőt osztanának meg az összes útvonalon.

Az életciklus szakaszai szakaszban leírtak szerint a konfigurált GatewayClassra hivatkozó átjáróerőforrás alkalmazásakor az átjáróvezérlő egyezteti azt az átjáróproxy üzembehelyezési erőforrásaival és a támogató erőforrásokkal. Az alhálózatok elhelyezését az átjáróerőforrás infrastruktúra-megjegyzéseivel szabályozhatja.

Ez a deklaratív modell nem igényel Helm-diagramokat, tárolólemezképeket vagy üzembehelyezési jegyzékfájlokat a proxyhoz. A szándékot az Átjáró API-erőforráskonfiguráción keresztül fejezi ki, és az átjáróvezérlő konvergálja a proxyt a kívánt állapot felé.

A felügyelt átjáróvezérlő általában éles üzemű alapértelmezett értékekkel helyezi üzembe az átjáróproxyt, beleértve a készültségi és élettartam-mintavételeket, az RBAC-engedélyeket, a cpu-alapú automatikus méretezéssel végzett replikaskálázást és egy PodDisruptionBudget, amely legalább egy elérhető podot tart fenn az önkéntes megszakítások során.

Bővítmény ütemezési topológiája

Az AKS-bővítmények felügyelt összetevőket helyeznek el a csomópontkészleteken azon ütemezési döntések alapján, amelyeket az alkalmazáscsapat nem szabályoz. A rendszer- és felhasználói csomópontkészletek méretezése előtt határozza meg, hogy az egyes engedélyezett bővítmények hol ütemezik a podokat. Egyes bővítmények tolerálják a rendszercsomópontkészletek szennyezettségeit, ezért csak a rendszerkészleten futnak. Más bővítmények célfelhasználói készletei. Ez a topológia közvetlenül befolyásolja az egyes készletekben szükséges kapacitást.

A felügyelt envoy gateway proxy a rendszercsomópont-készleten fut, nem pedig a felhasználói csomópontkészleten. Méretozza meg a rendszerkészletet a proxy további erőforrás-lábnyomának figyelembe vételéhez. Ha ez az alapértelmezett topológia nem felel meg a szervezet követelményeinek, például ha költségelkülönítési, hálózati szegmentálási vagy megfelelőségi okokból szüksége van a felhasználói készletek proxyjára, váltson egy ön által felügyelt átjáróvezérlőre, ahol csomópontelhelyezési döntéseket hozhat.

Felügyelt átjáróvezérlő használata esetén is az alkalmazáscsapat beállíthatja a pod anti-affinitást úgy, hogy a proxyreplikák a csomópontok között legyenek elosztva. Ezeket a beállításokat az engedélyezett átjáró testreszabási beállításaival konfigurálhatja. További információ: Átjáróerőforrás testreszabása.

Mivel az átjáróproxy a rendszercsomópont-készleten fut, és a számítási feladat a felhasználói csomópontkészleten fut, az ütemező független ütemezési tartományként kezeli őket. Az átjáróproxy és a számítási feladat szolgáltatásai gyakran kommunikálnak, mivel minden bejövő kérés a proxyn keresztül halad át a számítási feladat elérése előtt. Egyetlen beépített mechanizmus sem korrelálja a különböző csomópontkészletek podjai közötti zónaelhelyezést. Explicit útmutatás nélkül az ütemező olyan zónákba helyezheti a számítási feladat podjait, ahol nem létezik proxyreplika, így a forgalom átlépheti a rendelkezésre állási zónák határát, és késést és zónák közötti adatátviteli költségeket adhat hozzá.

A zónák közötti forgalom csökkentése érdekében konfiguráljon előnyben részesített podaffinitást a munkaterheléséhez, hogy az a proxyreplikákkal azonos zónába kerüljön. Ez a társhely a legközelebbi, amelyet akkor érhet el, ha a proxy és a számítási feladat külön csomópontkészleteken fut, mivel a csomópontszintű affinitás nincs hatással a készletekre. Vegye figyelembe, hogy az interpod affinitás feldolgozási többletterhelést okoz az ütemezőben, és nagy fürtökben lassú lehet az ütemezés.

Add-on resource requirements in governance policies

Az AKS-bővítmények olyan felügyelt összetevőket helyeznek üzembe, amelyek erőforrás-követelményeit nem az alkalmazáscsapat, hanem az AKS határozza meg és szabályozza. Amikor a fürt megtagadási módban kényszeríti ki a tárolóerőforrás-korlátozási szabályzatokat Azure Policy és az Open Policy Agent (OPA) Gatekeeper használatával, a szabályzatoknak minden engedélyezett bővítményt el kell fogadniuk. Ellenkező esetben a Gatekeeper csendesen letiltja a felügyelt podok létrehozását, amely anélkül tiltja le a platform képességeit, mint a bejövő forgalom, a titkos kódok szinkronizálása és a megfigyelhetőség, anélkül, hogy nyilvánvaló üzembe helyezési hibát mutatná.

A bővítményerőforrás-profilkészítést a szabályzatkészítés előfeltételeként kezelje. Mielőtt definiálna tároló cpu-, memória-, kötettípus- vagy biztonsági környezeti korlátozásokat, leltározza az összes engedélyezett bővítményt, és állapítsa meg a futtatókörnyezet erőforrás-követelményeit. A tényleges erőforrás-felhasználás valós forgalmi feltételek mellett történő rögzítéséhez használjon terheléstesztelést vagy szabályozott üzembe helyezéseket egy gyártás előtti környezetben. Ezután állítsa be a szabályzatkorlátokat úgy, hogy a bővítményösszetevők és a számítási feladatok tárolói is elférjenek. Ez a megközelítés biztosítja, hogy a szabályozási védőkorlátok a platform által felügyelt infrastruktúra zavarása nélkül védjék a fürtöt.

A felügyelt envoy-átjáróproxyhoz például replikánként legfeljebb 2 processzormagra és 1 GiB memóriára van szükség. Ezek az értékek valószínűleg meghaladják egy kis vagy alacsony erőforrásigényű számítási feladat igényeit. Állítsa be a szabályzatkorlátokat az átjáróproxy és az alkalmazástárolók elhelyezésére. E beállítás nélkül a Gatekeeper letiltja az átjáróproxy podjait, és a teljes bejövő folyamat nem valósul meg.

Fürtön belüli átjáró TLS-leállítása és HTTPS-kényszerítés

Ez az architektúra https protokollal konfigurálja az átjárót a 443-as porton egy Key Vault szinkronizált TLS-tanúsítvánnyal, és egy HTTP-figyelőt a 80-as porton az átirányításhoz. Az átjáró infrastruktúra-megjegyzései a terheléselosztót a bejövő alhálózatba helyezik, és belsővé teszik. A HTTP-figyelőhöz kötött átirányítási HTTPRoute visszatér 301 Moved Permanently az összes HTTP-kérés HTTPS-re való frissítéséhez. Az alkalmazás HTTPRoute a HTTPS-figyelőhöz kapcsolódik, és HTTP-en keresztül irányítja a forgalmat a számítási feladatok szolgáltatásához. Mivel az átjáróproxy TLS-megszakítást hajt végre, a háttérszolgáltatásokkal folytatott kommunikáció titkosítatlan.

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 pod-pod forgalom , amely magában foglalja az átjáróproxy é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 négy különböző forgalmi mintát mutat be az architektúrán belül. Az egyik mező a központi hálózatot tartalmazza egy Azure Firewall tartalmazó alhálózati mezővel. Egy külön doboz tartalmazza a küllős hálózatot, és alhálózati mezőket tartalmaz a Web Application Firewall (WAF), az AKS által felügyelt belső terheléselosztóhoz és az AKS-hez. A kétirányú fekete nyíl a két hálózat közötti virtuális hálózatok közötti társviszonyt mutatja. Az egyszínű zöld nyilak a nyilvános internetről a WAF-be irányuló, a küllős hálózaton, a WAF alhálózattól a belső terheléselosztó alhálózatig, onnan pedig az AKS-alhálózat felé irányuló, felhasználó által kezdeményezett kérésforgalmat jelenítik meg. Az egyszínű narancssárga nyilak a küllős hálózat AKS-alhálózatáról a központi hálózatra irányuló, a központi hálózat Azure Firewall alhálózatából a nyilvános internetre irányuló, fürt által kezdeményezett kérésforgalmat jelenítik meg. A pontozott narancssárga nyilak a nyilvános internetről a központi hálózat Azure Firewall alhálózatára, valamint a küllős hálózat AKS-alhálózatára irányuló válaszforgalmat jelenítik meg. A zöld pontozott nyilak az AKS alhálózatról a terheléselosztó alhálózatára, majd a küllős hálózat WAF alhálózatára, valamint a küllős hálózat WAF alhálózatáról a nyilvános internetre irányuló válaszforgalmat mutatják.

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 TLS-titkosított kéréseket fogad el az ügyféltől. A TLS 1.2-es verziója a minimálisan engedélyezett verzió, és korlátozott titkosítási halmazt tesz lehetővé. Az 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 1. lépés azt mutatja be, hogy egy felhasználó HTTPS-forgalmat küld az Application Gatewaynek. A 2. lépésben egy nyíl halad az Application Gatewayről az AKS-fürt envoy proxyja felé. A 3. lépésben egy nyíl látható, amely az Megbízott proxyról az AKS-fürt számítási feladataira mutat. A 4. lépés az Application Gateway és az Envoy proxytól a Key Vault felé haladó sorokat jeleníti meg, amelyek két tanúsítványt, bicycle.contoso.com és *.aks-ingress.contoso.com tartalmaznak. Minden TLS-végpont zárolási ikonnal van megjelölve.

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

1. Az ügyfél HTTPS-kérelmet küld a tartománynévnek: bicycle.contoso.comegy DNS A rekordhoz társított név az Application Gateway nyilvános IP-címére. 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. 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.

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

   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.

3. Az átjáróproxy a terheléselosztón keresztül fogadja a titkosított forgalmat. A proxy egy másik TLS-végződtetési pont *.aks-ingress.contoso.com számára, és HTTP-n keresztül továbbítja a forgalmat a munkaterhelési podokhoz.

4. Mindkét TLS-tanúsítvány Key Vault van tárolva.

   A fürt egy felhasználó által hozzárendelt felügyelt identitással fér hozzá a bicycle.contoso.com tanúsítványhoz, amely integrálható az Application Gatewayrel. További információ: TLS-leállítás Key Vault tanúsítványokkal. A TLS-tanúsítvány *.aks-ingress.contoso.com szinkronizálva van a fürtbe kubernetes-titkos kódként, amelyet az átjáró-erőforrás hivatkozik. További információ: Titkos kódkezelés hozzáadása.

A végpontok közötti TLS-forgalmat minden ugrásnál implementálhatja. Mindenképpen vegye figyelembe a podok közötti forgalom védelmére vonatkozó döntések teljesítményét, késését és működési hatásait. A legtöbb olyan egybérlős fürt esetében, amely rendelkezik megfelelő RBAC vezérlősíkkal és kiforrott szoftverfejlesztési életciklussal, elegendő a TLS titkosítása az átjáróproxyig, és Web Application Firewall védelemmel. Ez a megközelítés minimálisra csökkenti a számítási feladatok kezelésével és a gyenge hálózati teljesítménnyel járó többletterhelé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 Teljes felügyelet 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 Teljes felügyelet 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.

Kifejezetten a Tárolóregisztrációs adatbázishoz használjon dedikált adatvégpontokat. Nélkülük a rendszerképrétegek letöltései a regiszter privát végpontja helyett egy *.blob.core.windows.net végpontra irányulnak át, és a kimenő tűzfalszabályoknak engedélyezniük kellene egy veszélyes, Blob Storage-ra vonatkozó általános helyettesítő karaktert. Ez a szabály engedélyezné a csomópontok kimenő forgalmát bármely Azure Storage-fiók felé. A dedikált adatvégpontok lecserélik a helyettesítő karaktert a regisztrációs adatbázis-specifikus teljes tartománynevekre (FQDN-ekre) (<registry>.<region>.data.azurecr.io), amelyek a Private Linken keresztül az Ön privát végpontjára oldódnak fel, így a rendszerképrétegek forgalma a privát útvonalon marad, és lehetővé teszik, hogy a kimenőforgalmi szabályokat a fürt regisztrációs adatbázisára korlátozza.

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. A tűzfal forráshálózati címfordítást (SNAT) alkalmaz a kimenő adatforgalmakra, a pod IP-címét az adatforgalmak során az egyik csatolt nyilvános IP-címére cseréli, és a kijelölés nem determinisztikus. Adja hozzá a csatolt nyilvános IP-címek teljes készletét a célszolgáltatás IP-engedélyezési listájához, vagy használjon nyilvános IP-cím előtagot a készlet egybefüggő tartományként való kifejezésére.

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. A csatlakoztatott nyilvános IP-címek száma az SNAT-portkészletet is korlátozza, ezért a fürt egyidejű kimenő kapcsolati határa. Mielőtt elérné a portkimerülést, tervezze meg a Azure Firewall több IP-címét. Olyan fürtök esetében, amelyek nagyszámú egyidejű kimenő kapcsolatot nyitnak meg, csatoljon egy Azure NAT Gateway-t a AzureFirewallSubnet, hogy jelentősen bővítse az SNAT-portkészletet, és közben tartsa az összes kimenő forgalmat tűzfalvizsgálat alatt.

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. A kritikus hálózati folyamatok blokkolásának megakadályozása érdekében körültekintően alkalmazza a szabályzatokat. Szükség esetén csak meghatározott kommunikációs útvonalak, például az átjáróproxy és a számítási feladat közötti forgalom engedélyezése. Mivel az átjáróproxy ugyanabban a névtérben fut, mint a számítási feladat, a pod címkéje alapján célozza meg, ne névtérválasztóval. További információ: Network-szabályzatok.

Engedélyezze a hálózati házirendet a fürt beállításakor, mert később nem adhatja hozzá. Az NetworkPolicy technológiák implementálására több lehetőség közül választhat. Azure hálózati szabályzathoz 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. Az összes vezérlősík- és csomópontkészlet-forgalom a magánhálózaton marad, és nem lesz kitéve a nyilvános internetnek. A referencia-implementáció egy privát fürtöt hoz létre az API-kiszolgáló virtuális hálózati integrációjával. Az alacsonyabb környezetekben érdemes lehet enyhíteni ezt a privát fürtjavaslatot a kényelem érdekében, de az éles AKS-fürtöket mindig magánfürtként kell üzembe helyezni a biztonságos üzembehelyezé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:

• Tunneling: A Azure Bastion használatával közvetlenül a fürt API-kiszolgálója felé nyithat meg egy alagutat.
• Jump box: Kiépíteni egy jump-box virtuális gépet, és a Azure Bastion használatával SSH-val vagy RDP-vel csatlakozhat hozzá. 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.

Ez az architektúra Azure Bastion natív ügyfélalagutatással csatlakoztatja egy operátor helyi gépét a privát AKS API-kiszolgálóhoz Azure CLI parancsokkal. Az alagút támogatja a közvetlen kubectl- és Helm-munkafolyamatokat jump box nélkül. Ez a megközelítés azért ajánlott, mert az AKS API-végpontot privát állapotban tartja, miközben egyszerűbb és kevésbé költséges működést biztosít, mint egy jump box. A több operátor közötti koordináció is kevésbé bonyolult.

Az alábbi követelmények bármelyike esetén azonban választhatja a jump box használatát:

• Az operátorok nem biztonságos eszközöket használnak. Ha az ügyféleszközök nem megbízhatók, a jump boxok erősebb biztonsági szigorítást biztosíthatnak.

• Az operátorok instabil hálózatokon keresztül csatlakoznak. A jump box stabilabb kapcsolatot biztosíthat 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 bizonyos diagnosztikai eszközök, például a csomagrögzítés, nem működnek megfelelően az alagutas megközelítésekkel.

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 a 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, és az alapvető titkos kulcsokat az üzembehelyezési folyamaton kívül tartja. Ebben az architektúrában engedélyezve és konfigurálva van egy Key Vault tűzfal, Private Link pedig Azure erőforrásokhoz való csatlakozáshoz, például titkos kódokhoz é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 a számítási feladatok identitásainak hozzárendelését a Key Vault Titkos kulcsok felhasználója vagy Key Vault Olvasó szerepkör hozzárendeléséhez a titkos kódok eléréséhez. 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 titkos kulcstár CSI-illesztővel rendelkező Key Vault használja a manuális TLS-konfigurációs megközelítéssel. A SecretProviderClass erőforrás határozza meg, hogy mely Key Vault-tanúsítványokat kell Kubernetes Secretként a fürtbe szinkronizálni. A CSI-illesztőnek legalább egy podra van szüksége a megfelelő CSI-kötet csatlakoztatásához a szinkronizált titkos kód létrehozásához és karbantartásához. Ha törli az összes csatlakoztatott podot, az illesztőprogram szemétként gyűjti a titkos kulcsot, ami azt jelenti, hogy az átjáró elveszíti a TLS-tanúsítványát. Ennek elkerülése érdekében helyezzen üzembe egy dedikált, mindig futó podot, amely a CSI-kötetet a számítási feladat podok életciklusától függetlenül csatlakoztatja.

Ez az architektúra a busybox tároló lemezképét használja, amely egy egyszerűsített tárolót futtat egy próbafeladattal. Importálja a tárolólemezképet a fürt létrehozása előtt Azure Container Registry, mert a Flux üzembe helyezi azt a rendszerindítás során. Engedélyezze a titkos kulcsok rotálását, és állítson be két perchez hasonló rotációs lekérdezési időközt a CSI-bővítményen, hogy Key Vault tanúsítványmegújítások automatikusan propagáljanak. Az átjáró-erőforrás a https-megszakítás szinkronizált TLS-titkos kódjára hivatkozik. További információkért lásd: A bejövő (ingress) forgalom védelme az alkalmazásútválasztás Gateway API-megvalósításával.

Amint azt az AKS Azure-összetevőkhöz való hozzáférése is jelzi, ezt a manuális konfigurációt lecserélheti az operátor által felügyelt TLS-megközelítésre. Ezzel a módszerrel a Key Vault tanúsítvány URI-jának és egy Workload Identity ServiceAccount-nak a deklarálása közvetlenül az átjáró figyelőjén. Az alkalmazás-útválasztási operátor ezután létrehozza a SecretProviderClass szolgáltatást, és automatikusan kijavítja az átjárótanúsítvány-referenciát, ami szükségtelenné teszi, hogy ezeket az erőforrásokat a fürt indításakor vagy egy dedikált TLS-szinkronizálási pod létrehozásakor hozza létre. Mindkét megközelítés a CSI-illesztőprogram rotációs mechanizmusára támaszkodik, hogy észlelje a Key Vaultból származó tanúsítványmegújításokat.

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 OPA Gatekeeperen keresztül valósítja meg 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ályzatkényszerí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 Tárolóregisztrációs adatbázishoz, az Application Gatewayhez vagy a Key Vault, amelyek a fürttel kommunikálnak. 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 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 naplózási módban, hogy tisztában legyen ezekkel a példányokkal.

• 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 az éles szabályzatok az előkészületi környezettel is érvényesítve vannak. 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.

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

Az implementáció olyan további szabályzatokat is beállít, amelyek nem részei a beépített kezdeményezéseknek. Ezek a házirendek Megtagadás módban vannak beállítva. Létezik például egy szabályzat, amely biztosítja, hogy a 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. 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.

• Fürt: A rendelkezésre állási zónákat csak a csomópontkészlet létrehozásakor állíthatja be. Később nem módosíthatók. A csomópontméreteket minden zónában támogatni kell, hogy a várt eloszlás lehetséges legyen. A 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, hanem a vezérlősíkra is vonatkozik. 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, az ACR állapottudatos feladatátvétele automatikusan egy egészséges replikára irányítja át a lekéréseket a globális végponton keresztül, anélkül hogy módosítani kellene a fürt konfigurációját.

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

Ha támogatnia kell az állapottartó számítási feladatokat, és be kell vezetnie a AKS Backupot, használja az Azure Policyt annak kikényszerítésére, hogy a fürtön be legyen állítva a biztonsági mentés. Az Azure Monitor ugyanazon, ebben az architektúrában már kialakított megfigyelési veremen keresztül biztosítja a biztonsági mentési feladatok állapotának láthatóságát. Az irányításon túl a következő architekturális szempontokat kell figyelembe vennie a tervezésben:

• Biztonsági mentés hatóköre. Döntse el, hogy biztonsági másolatot készít-e a teljes fürtről vagy csak meghatározott névterekről. Az AKS Backup egy blobtárolóban és lemez- vagy fájlpillanatképként tárolja az adatokat. Ezt a hatókört korán definiálhatja, mert meghatározza a tárfiók méretezését, a megőrzési szabályzatokat és a helyreállítási részletességet olyan forgatókönyvek esetében, mint az operatív helyreállítás, a környezeti klónozás és a fürtfrissítések.
• Megbízható hozzáférés. Az AKS biztonsági mentése megbízható hozzáférést igényel a Backup-tároló és az AKS-fürt között, függetlenül attól, hogy a fürt nyilvános, privát vagy IP-címkorlátos.
• RBAC-engedélyek. A biztonsági mentési tároló felügyelt identitásának bizonyos engedélyekre van szüksége az AKS-fürtön a biztonsági mentések konfigurálásához és végrehajtásához. A biztonsági mentési bővítmény emellett létrehoz egy felhasználói identitást is, amely engedélyekkel rendelkezik azon a tárfiókon, ahol a biztonsági másolatok vannak tárolva.
• Kimenő hálózati forgalom. A biztonsági mentési bővítmény a fürtben lévő Azure Backup szolgáltatásokkal kommunikál. Adja meg a szükséges kimenő végpontokat a Azure Firewall és az NSG-szabályokban.
• Fürtön belüli lábnyom. A bővítmény podokat helyez üzembe a csomópontokon. Tervezze meg a csomóponterőforrás-költségvetésekben a további számítási és memóriahasználatot, és foglalja bele a bővítménynévteret a hálózati házirend-szabályozásba.

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 szolgáltatások 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.

Ha a rendszerindítási jegyzékekhez olyan értékek szükségesek, amelyek csak az üzembe helyezéskor ismertek, például tárolóregisztrációs adatbázis URL-címe, Key Vault neve vagy identitásügyfél-azonosító, használja a Flux változó helyettesítését a kustomizálási konfigurációban. A kustomizáció határozza meg, hogy a Git-adattár mely elérési útját kell egyeztetni, és mely build utáni változóhelyettesítéseket kell alkalmazni. A kustomizációkat a Flux-bővítmény üzembe helyezésének részeként konfigurálja az IaC-sablonban, amelyben meghatározza a helyettesítési változókat, hogy az értékek a fürt létrehozásakor az üzembe helyezett erőforrásokból oldódjanak fel. Ez a módszer kiküszöböli azokat az időzítési problémákat, amelyek akkor merülnek fel, amikor a ConfigMap-nak az első egyeztetés előtt léteznie kell, és nem követeli meg, hogy a felhasználók elágasszák az adattárat kizárólag a környezetspecifikus értékek testreszabásához. A Flux-bővítményügynök ezt az IaC-konfigurációt a Flux Kustomize vezérlő által egyeztetett egyéni Kubernetes-erőforrásokra fordítja, és a változócseréket alkalmazza az egyes útvonalak feldolgozásakor.

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. Ez a becslés a fürthöz közvetlenül társított küllőszintű erőforrásokra vonatkozik. A megosztott központi infrastruktúra, például a Azure Firewall, a központi virtuális hálózatok és a Azure saját DNS zónák nem szerepelnek benne, mivel ezek az erőforrások általában egy központi platformcsapat tulajdonában és kezelésében vannak.

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

Tip

Ez a cikk az AKS-fürtök átfogó tervezési szempontjait ismerteti. Az AKS Automatic számos tervezési döntést implementál, hogy csökkentse az értékelendő szempontok számát, és optimalizálja a gyakori használati eseteket. Az AKS Automatic például egy felügyelt rendszercsomópontkészletet helyez üzembe és üzemeltet, így a jelen cikkben szereplő rendszercsomópont-készlet méretezési, elkülönítési és frissítési döntései nem vonatkoznak erre a platformra.

Még akkor is, ha a számítási feladat egy AKS Automatikus környezetben lesz üzemeltetve, a saját felügyeletű AKS-fürt alapjainak ismerete segíthet a megfelelő döntések meghozatalában a számítási feladat módosításakor.

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
Alkalmazás útválasztása

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íl az AKS-fürtről a Azure Monitor munkaterületszakaszra mutat, 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ügyeleti műveletekhez 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.

Belső terheléselosztó IP-címeinek alhálózata

Ez az alhálózat biztosítja a belső terheléselosztó előtérbeli IP-címterét. Az Application Gateway forgalmat küld a hozzárendelt belső terheléselosztó IP-címére, a terheléselosztó pedig a fürt bármely csomópontja felé osztja el a forgalmat.

A fogadó csomópont kube-proxyügynöke továbbítja a csomagot a rendszercsomópont-készlet átjáróproxy-podjának, ami további hálózati ugrást is jelenthet. A proxy leállítja a Transport Layer Security (TLS) protokollt, és HTTP-n keresztül továbbítja a kérelmeket a számítási feladatok podjaira.

Ha dedikált alhálózatot használ az előtérbeli terheléselosztó IP-címeihez, olyan hálózati biztonsági csoport (NSG) szabályokat alkalmazhat, amelyek a terheléselosztó felé irányuló bejövő forgalmat a csomópont alhálózatának befolyásolása nélkül hatókörzik. További információ: A belső load balancer AKS.

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

Ez az architektúra két csomópontkészletet használ, amelyek külön csomópontcsoportok. A rendszercsomópont-készlet az alapvető fürtszolgáltatásokat futtató podokat üzemelteti, beleértve az átjáróproxyt is, amely a forgalmat a számítási feladathoz irányítja. A felhasználói csomópontkészlet futtatja a számítási feladatot.

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, és ugyanazon a virtuális hálózaton tartja a fürthöz tartozó erőforrásokat. Az alhálózat szintjén részletes biztonsági szabályokat is alkalmazhat az 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ó, valamint a fürt belső és külső ügyfelei 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özponti virtuális hálózat Azure Firewall, Azure Bastion és átjáróalhálózattal rendelkezik. A küllős virtuális hálózat alhálózatokkal rendelkezik az Application Gatewayhez, a bejövő forgalomhoz, a csomópontokhoz, a privát végpontokhoz és egy privát fürthöz. A nyilak a küllős hálózatok és a központi hálózat közötti társviszony-létesítési kapcsolatokat mutatják.

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

Ez a referenciaarchitektúra a következő hálózati megközelítéseket használja, amelyek mindegyike külön 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 Azure tárolóhálózati felület (CNI) átfedése, amellyel a fürt ip-címeket rendel a podokhoz a Azure virtuális hálózattól különálló címtérből.

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 alhálózatot eredményez. Az átjáró topológiája azért is kibővülhet, mert minden átjáró-erőforrás saját átjáróproxy-üzembe helyezést és terheléselosztó előtérbeli IP-címét állítja elő. Ennek megfelelően tervezze meg az alhálózat címterét.

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 az Osztály nélküli Inter-Domain Útválasztás (CIDR) tartományhoz /16 címteret használ, a fürt 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, csak azokat, amelyek jelentős értéket adnak 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.

Érdemes lehet kiértékelni néhány más előzetes verziójú funkciót vagy AKS-bővítményt 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. Minden nem Microsoft bővítményt telepítenie és karbantartania kell, amely 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 fürt tartalmazhatja a munkaterhelést és számos más rendszerképet, például saját felügyeletű átjáró-infrastruktúrát vagy egy olyan segédtárolót, amely szinkronizálja a TLS-tanúsítványokat a Key Vaultból. E képfájlok némelyike nyilvános regiszterekben is megtalálható lehet, de bevált gyakorlat, hogy azokat átvizsgálva, auditálva és egy dedikált privát regiszterben, például az Azure Container Registryben tárolja. 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. A referencia-implementációban a fürt csak a fürttel üzembe helyező dedikált Azure Container Registry példányról kér le 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. 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.

• A fürt kapacitásának tervezésekor tegyük fel, hogy a számítási feladat az egyes csomópontok legfeljebb 80% használ fel. 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. A referencia-implementáció Azure Linuxot használ, amely egy egyszerű, edzett Linux-disztribúció, amely Azure 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éssel vagy a futtatókörnyezettel kapcsolatos 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 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 külső és a külső 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ülső hozzáférés: Adjon meg identitásokat a Kubernetes-fürthöz való hozzáféréssel. 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. Szolgáltatásnevek esetén manuálisan vagy programozott módon kell kezelnie és elforgatnia a titkos kulcsokat. Felügyelt identitások esetén Microsoft Entra ID kezeli és végrehajtja a titkos kódok hitelesítését és időben történő rotálását.

Javasoljuk, hogy engedélyezze és használja 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 Registry használatával hitelesít. Egyes bővítmények a felügyelt identitás használatával is támogatják a hitelesítést.

Felügyelt identitást kell használnia, ha a fürtnek lemezképeket kell lekérnie egy tárolóregisztrációs adatbázisból. Ehhez a művelethez a fürtnek le kell szereznie a beállításjegyzék hitelesítő adatait, amelyet a fürt kubelet által felügyelt identitásának AcrPull a beállításjegyzékhez való hozzáférésével engedélyezhet. Ha nem használ felügyelt identitást, ezeket az adatokat egy Kubernetes-titkos kódban tárolhatja, és imagePullSecrets lekérheti. Ezt a megközelítést nem javasoljuk, mert biztonsági összetettségeket vezet be, például előre ismernie kell a titkos kódot, és a DevOps-folyamatban kell tárolnia. 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 Azure olyan erőforrásokhoz fér hozzá, amelyeket Microsoft Entra ID biztonságossá, és a fürt felügyelt identitásokat támogató műveleteket hajt végre. A fürt által végzett műveletektől függően Azure szerepköralapú hozzáférés-vezérlési (Azure RBAC-) szerepköröket és engedélyeket rendelhet a fürt felügyelt identitásaihoz. A fürt hitelesíti magát a Microsoft Entra ID, és a hozzá rendelt szerepkörök alapján engedélyezi vagy megtagadja a hozzáférést. A referencia-implementáció alábbi példái Azure a fürthöz rendelt beépített szerepköröket mutatják be:

• 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 rendszer által hozzárendelt identitása együttműködhet az átjáróproxyt és az AKS privát API-kiszolgálót kezelő belső terheléselosztó dedikált alhálózatával.

• A saját 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 privát DNS-zóna használatával tartják távol a DNS-rekordokat a nyilvános internetről, de továbbra is létrehozhatnak nyilvános DNS-címmel rendelkező privát AKS-fürtöt. Javasoljuk, hogy kifejezetten tiltsa le ezt a funkciót enablePrivateClusterPublicFQDN úgy, hogy false megakadályozza 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.

Két AKS-bővítmény további felügyelt identitásokat épít ki, amelyek szerepkör-hozzárendeléseket igényelnek. A Titkos kulcstár CSI-illesztőprogram bővítmény identitása lekéri a TLS-tanúsítványokat Key Vault. Az alkalmazás-útválasztási bővítmény identitása kezeli a DNS-rekordokat és az átjáró egyeztetését.

Adjon hozzáférést a két identitásnak az általuk használt erőforrásokhoz:

• A Titkos kulcstár csi-illesztőprogram felügyelt identitás bővítményének szüksége van a key vault Key Vault tanúsítványfelhasználói szerepkörére, hogy az illesztőprogram le tudja kérni a TLS-tanúsítványokat.

  Note

  Alternatív megoldásként lecserélheti a CSI Driver bővítmény felügyelt identitását Microsoft Entra számítási feladat identitására Key Vault hozzáféréshez. Számítási feladat identitásának használatakor összevont hitelesítő adatokkal köt egy felhasználó által hozzárendelt felügyelt identitást egy Kubernetes ServiceAccounthoz, és hivatkozik a ServiceAccountra az átjáró figyelőjének TLS-beállításai között. Az alkalmazás-útválasztási bővítmény ezután automatikusan létrehozza a SecretProviderClass szolgáltatást.

  Általában vagy a bővítmény felügyelt identitását, vagy a Workload Identityt választja a Key Vaulthoz a CSI-illesztőprogramon keresztüli hozzáféréshez. A Számítási feladatok identitása névtér hatókörű identitáselkülönítést biztosít, és csökkenti a manuális erőforrás-kezelést a hozzáadott identitások összevont hitelesítő adatokon keresztüli megkeményedésének költségén.

• Az alkalmazás-útválasztási bővítmény felügyelt identitásának szüksége van a Key Vault Titkos kulcsok felhasználója és Key Vault Olvasó szerepkörökre a key vault. Ahhoz, hogy a beépített DNS-összetevő összeegyeztethesse az átjáró erőforrásait, ehhez az identitáshoz szükség van a saját DNS zóna közreműködői szerepkörére is a bejövő private DNS zónában.

  Note

  A bővítményben üzembe helyezett beépített DNS-összetevő nem egyezteti automatikusan a DNS-rekordokat. Átjáró API-rekordjaihoz használja a Számítási feladatok identitása megközelítést.

További információ: Azure DNS és TLS konfigurálása az alkalmazás-útválasztási átjáró API-implementációval.

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.

A referencia-implementációban a helyi fürtfiókok hozzáférése kifejezetten tilos, amikor a rendszer üzembe helyezi a fürtöt.

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. A számítási feladat például fájlokat tárolhat Azure Storage. Amikor a podnak hozzá kell férnie ezekhez a fájlokhoz, az Azure felügyelt identitásként hitelesíti magát az erőforráson.

A referencia-implementációban az AKS Microsoft Entra Számítási feladat ID biztosítja a podok felügyelt identitásait. Ez a megközelítés integrálható a Kubernetes natív képességeivel a külső identitásszolgáltatókkal való összevonáshoz. 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 két hálózati modellben biztosít CNI-beépülő modulokat: á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ózaton 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 az implementáció Azure CNI Overlay-t használ, egy átfedéses hálózati beépülő modult, amely csak csomópontokhoz rendeli a virtuális hálózati IP-címeket, és pod IP-címeket rendel 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.

Alkalmazás útválasztása

Ez az architektúra a Kubernetes Gateway API alkalmazás-útválasztási bővítményét használja. Az alkalmazásútválasztási bővítmény egy olyan AKS-fürtkonfiguráció, amely előírja, hogy a fürt felügyelt átjáró-infrastruktúrát tartalmazzon. Az Átjáró API a Kubernetes egyéni erőforrásdefinícióinak (CRD-k) készlete, beleértve a GatewayClass, Gateway, HTTPRouteés másokat is. A Kubernetes-közösség az átjáró API-t jelölte ki az előző bejövő API utódjaként. Az Átjáró API szabványosított, szerepkör-orientált és bővíthető keretrendszert biztosít a forgalomkezeléshez.

Az Átjáró API-összetevők az alábbi életciklus-szakaszokban telepíthetők:

• Klaszter tervezése. Az alkalmazáscsapat dönti el, hogy melyik átjáróvezérlő kezelje a bejövő forgalmat, és hogyan kezelje a vezérlő életciklusát. Az átjáróvezérlők általában összecsomagolják az adatsík-proxyikat, így ez a döntés azt is meghatározza, hogy melyik proxy kezeli a forgalmi útvonalat. Ez az architektúra lehetővé teszi a felügyelt Gateway API CRD-k használatát. Úgy konfigurálja a bővítményt, hogy a felügyelt Istio-t használja átjáróvezérlőként, amely az Envoyval párosítja az átjáróproxyt. Bár az Istio szolgáltatáshálóként is használható, ez az architektúra csak az Istio-t használja átjáróvezérlőként, és nem engedélyezi a szolgáltatásháló képességeit.

  Ha a csapat más implementációt igényel, más átjáró API-vezérlőket is használhat, például NGINX-átjáró Fabric, Envoy Gateway és Traefik. Ezeknek a vezérlőknek az önkezeléséhez jegyzékek, affinitás-ellenesség, csomópontelhelyezés, mintavételek, RBAC-hatókörkezelés, méretezési szabályzatok, forrás IP-korlátozások és verzióéletciklus szükséges. Cserébe a csapatok teljes körű irányítást kapnak a proxy viselkedése, a fürtfrissítések és a nem konfigurált konfigurációktól független verzió-rögzítés felett.

• Fürtkiépítés. Ebben a szakaszban nem születnek tervezési döntések. Az AKS telepíti az Átjáró API CRD-jait, az Istio átjáróvezérlő podjait a aks-istio-system névtérben és a approuting-istio GatewayClass-t. Ebben a szakaszban nincsenek az átjáróproxyhoz tartozó adatsík-podok.

• Klaszter inicializálása. A számítási feladatokért felelős csapat meghatározza, hogy az átjáróproxy belső vagy külső terheléselosztón keresztül van-e közzétéve, melyik alhálózat üzemelteti a terheléselosztó előtérbeli IP-címét, és melyik névtérben fut az átjáróproxy. Ebben az architektúrában az átjáróproxy egy belső terheléselosztón jelenik meg. A terheléselosztó IP-címeinek dedikált alhálózata van, és az átjáróproxy a a0008 számítási feladat névterében van üzembe helyezve.

  A(z) approuting-istio GatewayClass-ra hivatkozó Gateway-erőforrás ezeket a döntéseket fejezi ki. Az átjáróvezérlő egyezteti az erőforrást az envoy gateway proxy üzembe helyezéseivel, a LoadBalancer szolgáltatással, a HorizontalPodAutoscalerrel és a PodDisruptionBudgettal ugyanabban a névtérben, mint az átjáróerőforrás.

  Ha egy privát DNS-zóna csatlakozik a bővítményhez, a bővítmény DNS-összetevője kezelheti a DNS A rekordokat, így nem kell statikus rekordokat fenntartania az infrastruktúrában kódsablonként (IaC). A kezdeti rendszerindítás a A klasztertitkok elérése című részben leírt, a TLS-tanúsítványok szinkronizálásához szükséges erőforrásokat is üzembe helyezi.

  Note

  A bővítménnyel telepített beépített DNS-összetevő nem szinkronizálja automatikusan a DNS-rekordokat a Gateway API-erőforrások használatakor. A privát DNS-rekordok automatikus egyeztetésének engedélyezéséhez helyezzen üzembe egy ClusterExternalDNS vagy ExternalDNS egyéni erőforrást. Az alkalmazás-útválasztási operátor összetevő ezután üzembe helyez egy felügyelt external-dns példányt, amely figyeli az átjáró- és HTTPRoute-erőforrásokat, és közzéteszi az A rekordokat a csatolt DNS-zónában.

  Mivel a DNS-zónába való íráshoz RBAC-engedélyekre van szükség, ehhez az integrációhoz Microsoft Entra számítási feladat identitására van szükség, beleértve a felhasználó által hozzárendelt felügyelt identitást a célzóna DNS-zóna-közreműködőjével, a fürt OpenID Connect (OIDC) kiállítójában megbízható összevont identitási hitelesítő adatokat és egy dedikált Kubernetes ServiceAccountot. Értékelje ki a további identitásinfrastruktúra-követelményeket a biztonsági és üzemeltetési igényeknek megfelelően.

• Munkaterhelés telepítése. Az alkalmazás csapata határozza meg, hogy mely gazdagépnevek, útvonalak és háttérrendszerek fogadják a forgalmat. Az átjáróhoz kötődő HTTPRoute-erőforrások kifejezik ezeket az útválasztási döntéseket. Az átjáróvezérlő továbbítja a deklarált útválasztási viselkedést az Envoy-podoknak.

• Folyamatos karbantartás: A bővítmény az Istio-átjáróvezérlő verzióját az AKS-fürt verziójához kapcsolja, így a frissítések a fürtfrissítések mellett történnek ahelyett, hogy független életciklus-kezelést igényelnek. Ez a bővítmény kizárólag az Átjáróproxy-felügyelethez használja az Istio-t. Nem engedélyezi az oldalkocsi-injektálást vagy a teljes Istio szolgáltatáshálót, amely egy külön bővítmény.

Note

Önkezelést akkor válasszon, ha a számítási feladat olyan képességeket igényel, amelyeket a bővítmény még nem támogat, például a TLSRoute for Server Name Indication (SNI) átengedését, az egyéni Lua- vagy Wasm-beépülő modulokon keresztüli speciális forgalomátalakításokat, vagy ha a megfelelőség egy adott proxyterméket ír elő. Akkor is válassza az önkezelést, ha a proxyt függetlenítenie kell a fürtfrissítésektől, vagy ha a fürt már használja az Istio service mesh bővítményt, mert a két bővítmény nem létezhet együtt.

Átjáró- és HTTPRoute-erőforrások alkalmazása

Ez az architektúra a Kubernetes Gateway API alkalmazás-útválasztási bővítményét használja a bejövő forgalom kezelésére. Ez a szakasz az előző szakaszban ismertetett fürtindítási és számítási feladatok üzembe helyezési fázisait ismerteti. Ezen a ponton az átjáróvezérlő fut, és várja az átjáró API-erőforrások egyeztetését.

Az Átjáró API egy szállítósemleges szabvány, amely a TLS-szabályzatot, a fejlécalapú útválasztást és a forgalomfelosztást natív API-mezőkként fejezi ki a implementációspecifikus széljegyzetek helyett. Mivel az útválasztási konfiguráció nem függ egy adott proxytechnológiától, később anélkül módosíthatja a mögöttes implementációt, hogy újraírta volna. Az alkalmazás-útválasztási bővítmény diktálja az átjáróvezérlőt és a proxy életciklusát, ami szükségtelenné teszi a frissítések, a biztonsági javítások, a skálázási konfiguráció és az RBAC-hatókörkezelés kezelését.

Az Átjáró API két olyan erőforrásra választja el a bejövő forgalmat, amelyek egymástól függetlenül változnak:

• Az átjáró-erőforrás deklarálja a hálózati felületet, beleértve a közzéteendő portokat és protokollokat, a TLS-tanúsítványokat és a belső terheléselosztó alhálózatát. Ez az erőforrás ritkán változik, és a hozzá tartozó összes útvonalra hatással van.

• A HTTPRoute-erőforrás deklarálja az útválasztási logikát, vagy azt, hogy mely gazdagépeket, útvonalakat és fejléceket rendeli hozzá a háttérszolgáltatásokhoz. Ez az erőforrás minden üzembe helyezéskor megváltozik, és az egyes szolgáltatásokra terjed ki.

Ez az architektúra csökkenti annak kockázatát, hogy egy útválasztási változás megzavarja a hálózati konfigurációt, vagy fordítva, mivel minden erőforrás eltérő változási ütemű és robbanási sugarú. Emellett több függőséget is eltávolít.

• Az útválasztási konfiguráció nincs egy adott proxytechnológiához kötve.
• A proxyverzió az AKS-fürt verziójával együtt mozog ahelyett, hogy független nyomon követést igényel.
• Minden átjáró-erőforrás saját proxytelepítést kap ahelyett, hogy egyetlen vezérlőt osztanának meg az összes útvonalon.

Az életciklus szakaszai szakaszban leírtak szerint a konfigurált GatewayClassra hivatkozó átjáróerőforrás alkalmazásakor az átjáróvezérlő egyezteti azt az átjáróproxy üzembehelyezési erőforrásaival és a támogató erőforrásokkal. Az alhálózatok elhelyezését az átjáróerőforrás infrastruktúra-megjegyzéseivel szabályozhatja.

Ez a deklaratív modell nem igényel Helm-diagramokat, tárolólemezképeket vagy üzembehelyezési jegyzékfájlokat a proxyhoz. A szándékot az Átjáró API-erőforráskonfiguráción keresztül fejezi ki, és az átjáróvezérlő konvergálja a proxyt a kívánt állapot felé.

A felügyelt átjáróvezérlő általában éles üzemű alapértelmezett értékekkel helyezi üzembe az átjáróproxyt, beleértve a készültségi és élettartam-mintavételeket, az RBAC-engedélyeket, a cpu-alapú automatikus méretezéssel végzett replikaskálázást és egy PodDisruptionBudget, amely legalább egy elérhető podot tart fenn az önkéntes megszakítások során.

Bővítmény ütemezési topológiája

Az AKS-bővítmények felügyelt összetevőket helyeznek el a csomópontkészleteken azon ütemezési döntések alapján, amelyeket az alkalmazáscsapat nem szabályoz. A rendszer- és felhasználói csomópontkészletek méretezése előtt határozza meg, hogy az egyes engedélyezett bővítmények hol ütemezik a podokat. Egyes bővítmények tolerálják a rendszercsomópontkészletek szennyezettségeit, ezért csak a rendszerkészleten futnak. Más bővítmények célfelhasználói készletei. Ez a topológia közvetlenül befolyásolja az egyes készletekben szükséges kapacitást.

A felügyelt envoy gateway proxy a rendszercsomópont-készleten fut, nem pedig a felhasználói csomópontkészleten. Méretozza meg a rendszerkészletet a proxy további erőforrás-lábnyomának figyelembe vételéhez. Ha ez az alapértelmezett topológia nem felel meg a szervezet követelményeinek, például ha költségelkülönítési, hálózati szegmentálási vagy megfelelőségi okokból szüksége van a felhasználói készletek proxyjára, váltson egy ön által felügyelt átjáróvezérlőre, ahol csomópontelhelyezési döntéseket hozhat.

Felügyelt átjáróvezérlő használata esetén is az alkalmazáscsapat beállíthatja a pod anti-affinitást úgy, hogy a proxyreplikák a csomópontok között legyenek elosztva. Ezeket a beállításokat az engedélyezett átjáró testreszabási beállításaival konfigurálhatja. További információ: Átjáróerőforrás testreszabása.

Mivel az átjáróproxy a rendszercsomópont-készleten fut, és a számítási feladat a felhasználói csomópontkészleten fut, az ütemező független ütemezési tartományként kezeli őket. Az átjáróproxy és a számítási feladat szolgáltatásai gyakran kommunikálnak, mivel minden bejövő kérés a proxyn keresztül halad át a számítási feladat elérése előtt. Egyetlen beépített mechanizmus sem korrelálja a különböző csomópontkészletek podjai közötti zónaelhelyezést. Explicit útmutatás nélkül az ütemező olyan zónákba helyezheti a számítási feladat podjait, ahol nem létezik proxyreplika, így a forgalom átlépheti a rendelkezésre állási zónák határát, és késést és zónák közötti adatátviteli költségeket adhat hozzá.

A zónák közötti forgalom csökkentése érdekében konfiguráljon előnyben részesített podaffinitást a munkaterheléséhez, hogy az a proxyreplikákkal azonos zónába kerüljön. Ez a társhely a legközelebbi, amelyet akkor érhet el, ha a proxy és a számítási feladat külön csomópontkészleteken fut, mivel a csomópontszintű affinitás nincs hatással a készletekre. Vegye figyelembe, hogy az interpod affinitás feldolgozási többletterhelést okoz az ütemezőben, és nagy fürtökben lassú lehet az ütemezés.

Add-on resource requirements in governance policies

Az AKS-bővítmények olyan felügyelt összetevőket helyeznek üzembe, amelyek erőforrás-követelményeit nem az alkalmazáscsapat, hanem az AKS határozza meg és szabályozza. Amikor a fürt megtagadási módban kényszeríti ki a tárolóerőforrás-korlátozási szabályzatokat Azure Policy és az Open Policy Agent (OPA) Gatekeeper használatával, a szabályzatoknak minden engedélyezett bővítményt el kell fogadniuk. Ellenkező esetben a Gatekeeper csendesen letiltja a felügyelt podok létrehozását, amely anélkül tiltja le a platform képességeit, mint a bejövő forgalom, a titkos kódok szinkronizálása és a megfigyelhetőség, anélkül, hogy nyilvánvaló üzembe helyezési hibát mutatná.

A bővítményerőforrás-profilkészítést a szabályzatkészítés előfeltételeként kezelje. Mielőtt definiálna tároló cpu-, memória-, kötettípus- vagy biztonsági környezeti korlátozásokat, leltározza az összes engedélyezett bővítményt, és állapítsa meg a futtatókörnyezet erőforrás-követelményeit. A tényleges erőforrás-felhasználás valós forgalmi feltételek mellett történő rögzítéséhez használjon terheléstesztelést vagy szabályozott üzembe helyezéseket egy gyártás előtti környezetben. Ezután állítsa be a szabályzatkorlátokat úgy, hogy a bővítményösszetevők és a számítási feladatok tárolói is elférjenek. Ez a megközelítés biztosítja, hogy a szabályozási védőkorlátok a platform által felügyelt infrastruktúra zavarása nélkül védjék a fürtöt.

A felügyelt envoy-átjáróproxyhoz például replikánként legfeljebb 2 processzormagra és 1 GiB memóriára van szükség. Ezek az értékek valószínűleg meghaladják egy kis vagy alacsony erőforrásigényű számítási feladat igényeit. Állítsa be a szabályzatkorlátokat az átjáróproxy és az alkalmazástárolók elhelyezésére. E beállítás nélkül a Gatekeeper letiltja az átjáróproxy podjait, és a teljes bejövő folyamat nem valósul meg.

Fürtön belüli átjáró TLS-leállítása és HTTPS-kényszerítés

Ez az architektúra https protokollal konfigurálja az átjárót a 443-as porton egy Key Vault szinkronizált TLS-tanúsítvánnyal, és egy HTTP-figyelőt a 80-as porton az átirányításhoz. Az átjáró infrastruktúra-megjegyzései a terheléselosztót a bejövő alhálózatba helyezik, és belsővé teszik. A HTTP-figyelőhöz kötött átirányítási HTTPRoute visszatér 301 Moved Permanently az összes HTTP-kérés HTTPS-re való frissítéséhez. Az alkalmazás HTTPRoute a HTTPS-figyelőhöz kapcsolódik, és HTTP-en keresztül irányítja a forgalmat a számítási feladatok szolgáltatásához. Mivel az átjáróproxy TLS-megszakítást hajt végre, a háttérszolgáltatásokkal folytatott kommunikáció titkosítatlan.

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 pod-pod forgalom , amely magában foglalja az átjáróproxy é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 négy különböző forgalmi mintát mutat be az architektúrán belül. Az egyik mező a központi hálózatot tartalmazza egy Azure Firewall tartalmazó alhálózati mezővel. Egy külön doboz tartalmazza a küllős hálózatot, és alhálózati mezőket tartalmaz a Web Application Firewall (WAF), az AKS által felügyelt belső terheléselosztóhoz és az AKS-hez. A kétirányú fekete nyíl a két hálózat közötti virtuális hálózatok közötti társviszonyt mutatja. Az egyszínű zöld nyilak a nyilvános internetről a WAF-be irányuló, a küllős hálózaton, a WAF alhálózattól a belső terheléselosztó alhálózatig, onnan pedig az AKS-alhálózat felé irányuló, felhasználó által kezdeményezett kérésforgalmat jelenítik meg. Az egyszínű narancssárga nyilak a küllős hálózat AKS-alhálózatáról a központi hálózatra irányuló, a központi hálózat Azure Firewall alhálózatából a nyilvános internetre irányuló, fürt által kezdeményezett kérésforgalmat jelenítik meg. A pontozott narancssárga nyilak a nyilvános internetről a központi hálózat Azure Firewall alhálózatára, valamint a küllős hálózat AKS-alhálózatára irányuló válaszforgalmat jelenítik meg. A zöld pontozott nyilak az AKS alhálózatról a terheléselosztó alhálózatára, majd a küllős hálózat WAF alhálózatára, valamint a küllős hálózat WAF alhálózatáról a nyilvános internetre irányuló válaszforgalmat mutatják.

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 TLS-titkosított kéréseket fogad el az ügyféltől. A TLS 1.2-es verziója a minimálisan engedélyezett verzió, és korlátozott titkosítási halmazt tesz lehetővé. Az 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 1. lépés azt mutatja be, hogy egy felhasználó HTTPS-forgalmat küld az Application Gatewaynek. A 2. lépésben egy nyíl halad az Application Gatewayről az AKS-fürt envoy proxyja felé. A 3. lépésben egy nyíl látható, amely az Megbízott proxyról az AKS-fürt számítási feladataira mutat. A 4. lépés az Application Gateway és az Envoy proxytól a Key Vault felé haladó sorokat jeleníti meg, amelyek két tanúsítványt, bicycle.contoso.com és *.aks-ingress.contoso.com tartalmaznak. Minden TLS-végpont zárolási ikonnal van megjelölve.

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

1. Az ügyfél HTTPS-kérelmet küld a tartománynévnek: bicycle.contoso.comegy DNS A rekordhoz társított név az Application Gateway nyilvános IP-címére. 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. 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.

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

   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.

3. Az átjáróproxy a terheléselosztón keresztül fogadja a titkosított forgalmat. A proxy egy másik TLS-végződtetési pont *.aks-ingress.contoso.com számára, és HTTP-n keresztül továbbítja a forgalmat a munkaterhelési podokhoz.

4. Mindkét TLS-tanúsítvány Key Vault van tárolva.

   A fürt egy felhasználó által hozzárendelt felügyelt identitással fér hozzá a bicycle.contoso.com tanúsítványhoz, amely integrálható az Application Gatewayrel. További információ: TLS-leállítás Key Vault tanúsítványokkal. A TLS-tanúsítvány *.aks-ingress.contoso.com szinkronizálva van a fürtbe kubernetes-titkos kódként, amelyet az átjáró-erőforrás hivatkozik. További információ: Titkos kódkezelés hozzáadása.

A végpontok közötti TLS-forgalmat minden ugrásnál implementálhatja. Mindenképpen vegye figyelembe a podok közötti forgalom védelmére vonatkozó döntések teljesítményét, késését és működési hatásait. A legtöbb olyan egybérlős fürt esetében, amely rendelkezik megfelelő RBAC vezérlősíkkal és kiforrott szoftverfejlesztési életciklussal, elegendő a TLS titkosítása az átjáróproxyig, és Web Application Firewall védelemmel. Ez a megközelítés minimálisra csökkenti a számítási feladatok kezelésével és a gyenge hálózati teljesítménnyel járó többletterhelé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 Teljes felügyelet 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 Teljes felügyelet 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.

Kifejezetten a Tárolóregisztrációs adatbázishoz használjon dedikált adatvégpontokat. Nélkülük a rendszerképrétegek letöltései a regiszter privát végpontja helyett egy *.blob.core.windows.net végpontra irányulnak át, és a kimenő tűzfalszabályoknak engedélyezniük kellene egy veszélyes, Blob Storage-ra vonatkozó általános helyettesítő karaktert. Ez a szabály engedélyezné a csomópontok kimenő forgalmát bármely Azure Storage-fiók felé. A dedikált adatvégpontok lecserélik a helyettesítő karaktert a regisztrációs adatbázis-specifikus teljes tartománynevekre (FQDN-ekre) (<registry>.<region>.data.azurecr.io), amelyek a Private Linken keresztül az Ön privát végpontjára oldódnak fel, így a rendszerképrétegek forgalma a privát útvonalon marad, és lehetővé teszik, hogy a kimenőforgalmi szabályokat a fürt regisztrációs adatbázisára korlátozza.

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. A tűzfal forráshálózati címfordítást (SNAT) alkalmaz a kimenő adatforgalmakra, a pod IP-címét az adatforgalmak során az egyik csatolt nyilvános IP-címére cseréli, és a kijelölés nem determinisztikus. Adja hozzá a csatolt nyilvános IP-címek teljes készletét a célszolgáltatás IP-engedélyezési listájához, vagy használjon nyilvános IP-cím előtagot a készlet egybefüggő tartományként való kifejezésére.

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. A csatlakoztatott nyilvános IP-címek száma az SNAT-portkészletet is korlátozza, ezért a fürt egyidejű kimenő kapcsolati határa. Mielőtt elérné a portkimerülést, tervezze meg a Azure Firewall több IP-címét. Olyan fürtök esetében, amelyek nagyszámú egyidejű kimenő kapcsolatot nyitnak meg, csatoljon egy Azure NAT Gateway-t a AzureFirewallSubnet, hogy jelentősen bővítse az SNAT-portkészletet, és közben tartsa az összes kimenő forgalmat tűzfalvizsgálat alatt.

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. A kritikus hálózati folyamatok blokkolásának megakadályozása érdekében körültekintően alkalmazza a szabályzatokat. Szükség esetén csak meghatározott kommunikációs útvonalak, például az átjáróproxy és a számítási feladat közötti forgalom engedélyezése. Mivel az átjáróproxy ugyanabban a névtérben fut, mint a számítási feladat, a pod címkéje alapján célozza meg, ne névtérválasztóval. További információ: Network-szabályzatok.

Engedélyezze a hálózati házirendet a fürt beállításakor, mert később nem adhatja hozzá. Az NetworkPolicy technológiák implementálására több lehetőség közül választhat. Azure hálózati szabályzathoz 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. Az összes vezérlősík- és csomópontkészlet-forgalom a magánhálózaton marad, és nem lesz kitéve a nyilvános internetnek. A referencia-implementáció egy privát fürtöt hoz létre az API-kiszolgáló virtuális hálózati integrációjával. Az alacsonyabb környezetekben érdemes lehet enyhíteni ezt a privát fürtjavaslatot a kényelem érdekében, de az éles AKS-fürtöket mindig magánfürtként kell üzembe helyezni a biztonságos üzembehelyezé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:

• Tunneling: A Azure Bastion használatával közvetlenül a fürt API-kiszolgálója felé nyithat meg egy alagutat.
• Jump box: Kiépíteni egy jump-box virtuális gépet, és a Azure Bastion használatával SSH-val vagy RDP-vel csatlakozhat hozzá. 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.

Ez az architektúra Azure Bastion natív ügyfélalagutatással csatlakoztatja egy operátor helyi gépét a privát AKS API-kiszolgálóhoz Azure CLI parancsokkal. Az alagút támogatja a közvetlen kubectl- és Helm-munkafolyamatokat jump box nélkül. Ez a megközelítés azért ajánlott, mert az AKS API-végpontot privát állapotban tartja, miközben egyszerűbb és kevésbé költséges működést biztosít, mint egy jump box. A több operátor közötti koordináció is kevésbé bonyolult.

Az alábbi követelmények bármelyike esetén azonban választhatja a jump box használatát:

• Az operátorok nem biztonságos eszközöket használnak. Ha az ügyféleszközök nem megbízhatók, a jump boxok erősebb biztonsági szigorítást biztosíthatnak.

• Az operátorok instabil hálózatokon keresztül csatlakoznak. A jump box stabilabb kapcsolatot biztosíthat 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 bizonyos diagnosztikai eszközök, például a csomagrögzítés, nem működnek megfelelően az alagutas megközelítésekkel.

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 a 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, és az alapvető titkos kulcsokat az üzembehelyezési folyamaton kívül tartja. Ebben az architektúrában engedélyezve és konfigurálva van egy Key Vault tűzfal, Private Link pedig Azure erőforrásokhoz való csatlakozáshoz, például titkos kódokhoz é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 a számítási feladatok identitásainak hozzárendelését a Key Vault Titkos kulcsok felhasználója vagy Key Vault Olvasó szerepkör hozzárendeléséhez a titkos kódok eléréséhez. 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 titkos kulcstár CSI-illesztővel rendelkező Key Vault használja a manuális TLS-konfigurációs megközelítéssel. A SecretProviderClass erőforrás határozza meg, hogy mely Key Vault-tanúsítványokat kell Kubernetes Secretként a fürtbe szinkronizálni. A CSI-illesztőnek legalább egy podra van szüksége a megfelelő CSI-kötet csatlakoztatásához a szinkronizált titkos kód létrehozásához és karbantartásához. Ha törli az összes csatlakoztatott podot, az illesztőprogram szemétként gyűjti a titkos kulcsot, ami azt jelenti, hogy az átjáró elveszíti a TLS-tanúsítványát. Ennek elkerülése érdekében helyezzen üzembe egy dedikált, mindig futó podot, amely a CSI-kötetet a számítási feladat podok életciklusától függetlenül csatlakoztatja.

Ez az architektúra a busybox tároló lemezképét használja, amely egy egyszerűsített tárolót futtat egy próbafeladattal. Importálja a tárolólemezképet a fürt létrehozása előtt Azure Container Registry, mert a Flux üzembe helyezi azt a rendszerindítás során. Engedélyezze a titkos kulcsok rotálását, és állítson be két perchez hasonló rotációs lekérdezési időközt a CSI-bővítményen, hogy Key Vault tanúsítványmegújítások automatikusan propagáljanak. Az átjáró-erőforrás a https-megszakítás szinkronizált TLS-titkos kódjára hivatkozik. További információkért lásd: A bejövő (ingress) forgalom védelme az alkalmazásútválasztás Gateway API-megvalósításával.

Amint azt az AKS Azure-összetevőkhöz való hozzáférése is jelzi, ezt a manuális konfigurációt lecserélheti az operátor által felügyelt TLS-megközelítésre. Ezzel a módszerrel a Key Vault tanúsítvány URI-jának és egy Workload Identity ServiceAccount-nak a deklarálása közvetlenül az átjáró figyelőjén. Az alkalmazás-útválasztási operátor ezután létrehozza a SecretProviderClass szolgáltatást, és automatikusan kijavítja az átjárótanúsítvány-referenciát, ami szükségtelenné teszi, hogy ezeket az erőforrásokat a fürt indításakor vagy egy dedikált TLS-szinkronizálási pod létrehozásakor hozza létre. Mindkét megközelítés a CSI-illesztőprogram rotációs mechanizmusára támaszkodik, hogy észlelje a Key Vaultból származó tanúsítványmegújításokat.

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 OPA Gatekeeperen keresztül valósítja meg 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ályzatkényszerí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 Tárolóregisztrációs adatbázishoz, az Application Gatewayhez vagy a Key Vault, amelyek a fürttel kommunikálnak. 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 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 naplózási módban, hogy tisztában legyen ezekkel a példányokkal.

• 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 az éles szabályzatok az előkészületi környezettel is érvényesítve vannak. 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.

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

Az implementáció olyan további szabályzatokat is beállít, amelyek nem részei a beépített kezdeményezéseknek. Ezek a házirendek Megtagadás módban vannak beállítva. Létezik például egy szabályzat, amely biztosítja, hogy a 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. 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.

• Fürt: A rendelkezésre állási zónákat csak a csomópontkészlet létrehozásakor állíthatja be. Később nem módosíthatók. A csomópontméreteket minden zónában támogatni kell, hogy a várt eloszlás lehetséges legyen. A 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, hanem a vezérlősíkra is vonatkozik. 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, az ACR állapottudatos feladatátvétele automatikusan egy egészséges replikára irányítja át a lekéréseket a globális végponton keresztül, anélkül hogy módosítani kellene a fürt konfigurációját.

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

Ha támogatnia kell az állapottartó számítási feladatokat, és be kell vezetnie a AKS Backupot, használja az Azure Policyt annak kikényszerítésére, hogy a fürtön be legyen állítva a biztonsági mentés. Az Azure Monitor ugyanazon, ebben az architektúrában már kialakított megfigyelési veremen keresztül biztosítja a biztonsági mentési feladatok állapotának láthatóságát. Az irányításon túl a következő architekturális szempontokat kell figyelembe vennie a tervezésben:

• Biztonsági mentés hatóköre. Döntse el, hogy biztonsági másolatot készít-e a teljes fürtről vagy csak meghatározott névterekről. Az AKS Backup egy blobtárolóban és lemez- vagy fájlpillanatképként tárolja az adatokat. Ezt a hatókört korán definiálhatja, mert meghatározza a tárfiók méretezését, a megőrzési szabályzatokat és a helyreállítási részletességet olyan forgatókönyvek esetében, mint az operatív helyreállítás, a környezeti klónozás és a fürtfrissítések.
• Megbízható hozzáférés. Az AKS biztonsági mentése megbízható hozzáférést igényel a Backup-tároló és az AKS-fürt között, függetlenül attól, hogy a fürt nyilvános, privát vagy IP-címkorlátos.
• RBAC-engedélyek. A biztonsági mentési tároló felügyelt identitásának bizonyos engedélyekre van szüksége az AKS-fürtön a biztonsági mentések konfigurálásához és végrehajtásához. A biztonsági mentési bővítmény emellett létrehoz egy felhasználói identitást is, amely engedélyekkel rendelkezik azon a tárfiókon, ahol a biztonsági másolatok vannak tárolva.
• Kimenő hálózati forgalom. A biztonsági mentési bővítmény a fürtben lévő Azure Backup szolgáltatásokkal kommunikál. Adja meg a szükséges kimenő végpontokat a Azure Firewall és az NSG-szabályokban.
• Fürtön belüli lábnyom. A bővítmény podokat helyez üzembe a csomópontokon. Tervezze meg a csomóponterőforrás-költségvetésekben a további számítási és memóriahasználatot, és foglalja bele a bővítménynévteret a hálózati házirend-szabályozásba.

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 szolgáltatások 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.

Ha a rendszerindítási jegyzékekhez olyan értékek szükségesek, amelyek csak az üzembe helyezéskor ismertek, például tárolóregisztrációs adatbázis URL-címe, Key Vault neve vagy identitásügyfél-azonosító, használja a Flux változó helyettesítését a kustomizálási konfigurációban. A kustomizáció határozza meg, hogy a Git-adattár mely elérési útját kell egyeztetni, és mely build utáni változóhelyettesítéseket kell alkalmazni. A kustomizációkat a Flux-bővítmény üzembe helyezésének részeként konfigurálja az IaC-sablonban, amelyben meghatározza a helyettesítési változókat, hogy az értékek a fürt létrehozásakor az üzembe helyezett erőforrásokból oldódjanak fel. Ez a módszer kiküszöböli azokat az időzítési problémákat, amelyek akkor merülnek fel, amikor a ConfigMap-nak az első egyeztetés előtt léteznie kell, és nem követeli meg, hogy a felhasználók elágasszák az adattárat kizárólag a környezetspecifikus értékek testreszabásához. A Flux-bővítményügynök ezt az IaC-konfigurációt a Flux Kustomize vezérlő által egyeztetett egyéni Kubernetes-erőforrásokra fordítja, és a változócseréket alkalmazza az egyes útvonalak feldolgozásakor.

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. Ez a becslés a fürthöz közvetlenül társított küllőszintű erőforrásokra vonatkozik. A megosztott központi infrastruktúra, például a Azure Firewall, a központi virtuális hálózatok és a Azure saját DNS zónák nem szerepelnek benne, mivel ezek az erőforrások általában egy központi platformcsapat tulajdonában és kezelésében vannak.

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 5 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