Megosztás a következőn keresztül:

Mikroszolgáltatás-architektúra az Azure Kubernetes Service-ben

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Load Balancer
Azure Pipelines
Azure Monitor

Ez a referenciaarchitektúra az Azure Kubernetes Service-ben (AKS) üzembe helyezett mikroszolgáltatási alkalmazásokat mutatja be. Ez egy alapszintű AKS-konfigurációt ír le, amelyet a legtöbb üzembe helyezés kiindulópontjaként használhat. Ez a cikk feltételezi, hogy alapszintű ismereteket szerzett a Kubernetesről. A cikk elsősorban az AKS-beli mikroszolgáltatások kezelésének infrastruktúrával és DevOps-aspektusaival foglalkozik. További információ a mikroszolgáltatások tervezéséről: Mikroszolgáltatások architektúrájának tervezése.

GitHub-emblémát. Az architektúra referencia-implementációja elérhető GitHub.

Architektúra

Diagram, amely az AKS referenciaarchitektúrájának mikroszolgáltatásait mutatja be.

A Helm a Cloud Native Computing Foundation (CNCF) védjegye. A védjegy használata nem utal jóváhagyásra.

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

Ha egy fejlettebb mikroszolgáltatásra szeretne példát látni, amely az AKS alaparchitektúrájára épül, tekintse meg a fejlett AKS-mikroszolgáltatások architektúráját.

Munkafolyamat

Ez a kérési folyamat implementálja a közzétevő-előfizetői, versengő felhasználók, valamint átjáró-útválasztási felhőtervezési mintákat.

Az alábbi adatfolyam az előző diagramnak felel meg:

  1. Az ügyfélalkalmazás HTTPS-en keresztül küld JSON-hasznos adatokat a terheléselosztó (felügyelt bejövőforgalom-vezérlő) nyilvános teljes tartománynevére a drónfelvétel ütemezéséhez.

    • A felügyelt bejövőforgalom-vezérlő átirányítja a kérést a betöltési mikroszolgáltatáshoz.

    • A betöltési mikroszolgáltatás feldolgozza a kérést, és egy Azure Service Bus-üzenetsor kézbesítési kéréseit dolgozza fel.

  2. A munkafolyamat mikroszolgáltatása:

    • A Service Bus üzenetsorából származó üzenetadatokat használja fel.

    • HTTPS-kérést küld a kézbesítési mikroszolgáltatásnak, amely adatokat továbbít az Azure Cache for Redis külső adattárának.

    • HTTPS-kérést küld a drónütemező mikroszolgáltatásának.

    • HTTPS-kérést küld a csomag mikroszolgáltatásának, amely adatokat ad át a MongoDB külső adattárának.

  3. A HTTPS GET kérés visszaadja a kézbesítés állapotát. Ez a kérés a felügyelt bejövőforgalom-vezérlőn keresztül továbbítja a kézbesítési mikroszolgáltatásba. Ezután a kézbesítési mikroszolgáltatás beolvassa az adatokat az Azure Cache for Redisből.

A mikroszolgáltatás-mintaalkalmazással kapcsolatos további információkért lásd mikroszolgáltatásokra vonatkozó referencia-megvalósítási minta.

Összetevők

  • AKS az Azure-felhőben üzemeltetett felügyelt Kubernetes-fürt. Az AKS csökkenti a Kubernetes kezelésének összetettségét és működési többletterhelését azáltal, hogy a felelősség nagy részét kiterjesíti az Azure-ba.

  • Egy bejövő kiszolgáló http(s) útvonalakat tesz elérhetővé a fürt szolgáltatásainak. A referencia-implementáció egy felügyelt NGINX-alapú bejövőforgalom-vezérlőt használ, egy alkalmazás-útválasztási bővítményen keresztül. A bejövőforgalom-vezérlő implementálja a mikroszolgáltatások API-átjáró mintáját.

  • külső adattárakat, például Azure SQL Database vagy Azure Cosmos DBállapot nélküli mikroszolgáltatások használják adataik és egyéb állapotinformációik megírására. A referencia-implementáció Azure Cosmos DB, Azure Cache for Redis, Azure Cosmos DB for MongoDB és Service Bus adattárként vagy tárolóhelyként használja.

  • Microsoft Entra-azonosító szükséges az AKS-fürthöz. Egy felügyelt identitást biztosít, amely az Azure Container Registry eléréséhez, valamint az Azure-erőforrások, például a terheléselosztók és a felügyelt lemezek eléréséhez és kiépítéséhez használható. Az AKS-fürtökön üzembe helyezett számítási feladatokhoz a Microsoft Entra-ban is szükség van egy identitásra, hogy hozzáférjenek a Microsoft Entra által védett erőforrásokhoz, például az Azure Key Vaulthoz és a Microsoft Graphhoz. Ebben a referenciaarchitektúrában Microsoft Entra számítási feladatazonosító integrálható a Kubernetes szolgáltatással, és identitásokkal biztosítja a számítási feladatokat. Az egyes számítási feladatokhoz használhat felügyelt identitásokat vagy alkalmazás hitelesítő adatokat is.

  • Tárolóregisztrációs adatbázis a fürtben üzembe helyezett privát tárolólemezképek tárolására használható. Az AKS a Tárolóregisztrációs adatbázissal a Microsoft Entra-identitásával hitelesíthető. A referencia-implementációban a mikroszolgáltatások tárolólemezképei létrejönnek, és le lesznek küldve a Container Registrybe.

  • Azure Pipelines az Azure DevOps-csomag része, és automatizált buildeket, teszteket és üzembe helyezéseket futtat. A folyamatos integráció és folyamatos üzembe helyezés (CI/CD) megközelítés erősen ajánlott mikroszolgáltatási környezetekben. A különböző csapatok egymástól függetlenül hozhatnak létre és helyezhetnek üzembe mikroszolgáltatásokat az AKS-ben az Azure Pipelines használatával.

  • Helm a Kubernetes csomagkezelője, amely lehetővé teszi, hogy a Kubernetes-objektumokat egyetlen egységbe csomagolja és szabványosítsa, amely közzétehető, üzembe helyezhető, verziószámozott és frissíthető.

  • Azure Monitor- metrikákat és naplókat, alkalmazástelemetria- és platformmetrikákat gyűjt és tárol az Azure-szolgáltatásokhoz. Az Azure Monitor integrálható az AKS-sel a vezérlők, csomópontok és tárolók metrikáinak gyűjtéséhez.

  • Application Insights figyeli a mikroszolgáltatásokat és a tárolókat. Használható a mikroszolgáltatások megfigyelhetőségének biztosítására, amely magában foglalja a forgalom áramlását, a végpontok közötti késést és a hiba százalékos arányát. A mikroszolgáltatások állapota és a köztük lévő kapcsolatok egyetlen alkalmazástérképen jeleníthetők meg.

Alternatívák

Azure Container Apps felügyelt kiszolgáló nélküli Kubernetes-élményt biztosít. Az AKS egyszerűbb alternatívája a mikroszolgáltatások üzemeltetéséhez, ha nincs szüksége a Kuberneteshez vagy annak API-jaihoz való közvetlen hozzáférésre, és nincs szükség a fürtinfrastruktúra felügyeletére.

A felügyelt bejövő átjáró helyett az AKS-ben olyan alternatív megoldásokat használhat, mint az Application Gateway for Containers, az Istio bejövő átjáró vagy a nem Microsoft-megoldások. További információ: Bejövő forgalom az AKS.

Tárolólemezképeket tárolhat nem Microsoft-tárolóregisztrációs adatbázisokban, például a Docker Hubban.

Az állapotinformációkat karbantartó mikroszolgáltatások esetében Dapr absztrakciós réteget biztosít a mikroszolgáltatások állapotának kezeléséhez.

A GitHub Actions használatával mikroszolgáltatásokat hozhat létre és helyezhet üzembe, vagy választhat nem Microsoft CI-/CD-megoldásokat, például a Jenkinst.

A mikroszolgáltatások megfigyelhetősége olyan alternatív eszközökkel érhető el, mint Kiali.

Forgatókönyv részletei

A példa mikroszolgáltatás-referencia implementálási implementálja a cikkben ismertetett architekturális összetevőket és eljárásokat. Ebben a példában a Fabrikam, Inc. nevű fiktív vállalat drónrepülőgép-flottát kezel. A vállalkozások regisztrálnak a szolgáltatásban, és a felhasználók drónt kérhetnek az áruk kézbesítéséhez. Amikor egy ügyfél csomagfelvételt ütemez, a háttérrendszer hozzárendel egy drónt, és értesíti a felhasználót a becsült szállítási időről. Amikor a kézbesítés folyamatban van, az ügyfél folyamatosan frissített becsült kézbesítési idővel nyomon követheti a drón helyét.

A forgatókönyv célja a mikroszolgáltatások architektúrájának és üzembe helyezésének ajánlott eljárásainak bemutatása az AKS-ben.

Lehetséges használati esetek

Az AKS-ben összetett mikroszolgáltatás-alapú alkalmazások létrehozásához kövesse az alábbi ajánlott eljárásokat a forgatókönyvből:

  • Összetett webalkalmazások
  • Mikroszolgáltatás-tervezési alapelvek alapján kifejlesztett üzleti logika

Megfontolások

Ezek a szempontok implementálják az Azure Well-Architected Framework alappilléreit, amely a számítási feladatok minőségének javítására használható vezérelvek készlete. További információ: Microsoft Azure Well-Architected Framework.

Tervezés

Ez a referenciaarchitektúra a mikroszolgáltatásokra összpontosít, de az ajánlott eljárások nagy része az AKS-en futó egyéb számítási feladatokra is vonatkozik.

Mikroszolgáltatások

A mikroszolgáltatások lazán összekapcsolt, egymástól függetlenül üzembe helyezhető kódegységek. A mikroszolgáltatások általában jól definiált API-kon keresztül kommunikálnak, és valamilyen szolgáltatásfelderítési formában észlelhetők. A Kubernetes szolgáltatásobjektum tipikus módja a mikroszolgáltatások modellezésének a Kubernetesben.

Adattárolás

A mikroszolgáltatás-architektúrában a szolgáltatásoknak nem szabad adattárolási megoldásokat megosztaniuk. Minden szolgáltatásnak saját adatkészletet kell kezelnie, hogy elkerülje a szolgáltatások közötti rejtett függőségeket. Az adatelválasztás segít elkerülni a szolgáltatások közötti véletlen összekapcsolást. Ez a folyamat akkor fordulhat elő, ha a szolgáltatások ugyanazokat a mögöttes adatsémákat osztják meg. Amikor a szolgáltatások saját adattárakat kezelnek, a megfelelő adattárat használhatják az adott követelményeknek megfelelően. További információ: Mikroszolgáltatások.

Kerülje az állandó adatok helyi fürttárolóban való tárolását, mert ez a módszer köti az adatokat a csomóponthoz. Ehelyett használjon egy külső szolgáltatást, például az SQL Database-t vagy az Azure Cosmos DB-t. Egy másik lehetőség az állandó adatkötet csatlakoztatása egy megoldáshoz az Azure Disk Storage vagy az Azure Files használatával. További információ: Tárolási lehetőségek az AKS-ben lévő alkalmazásokhoz.

API-átjáró

Az API-átjárók egy általános mikroszolgáltatás-tervezési minta. Az API-átjáró a külső ügyfelek és a mikroszolgáltatások között helyezkedik el. Az átjáró fordított proxyként szolgál, és átirányítja az ügyfelektől érkező kéréseket a mikroszolgáltatásokhoz. Az API-átjárók különböző horizontális feladatokat is végrehajthatnak, például a hitelesítést, a Secure Sockets Layer (SSL) leállítását és a sebességkorlátozást. További információt a következő források tartalmaznak:

A Kubernetesben a bejövőforgalom-vezérlő elsősorban az API-átjárók funkcióit kezeli. A bejövő és bejövőforgalom-vezérlő a következőkkel működik együtt:

  • Az ügyfélkérések átirányítása a megfelelő háttérbeli mikroszolgáltatásokhoz. Ez az útválasztás egyetlen végpontot biztosít az ügyfelek számára, és segít leválasztani az ügyfeleket a szolgáltatásokról.

  • Több kérés összesítése egyetlen kérelembe az ügyfél és a háttér közötti csevegés csökkentése érdekében.

  • Kiszervezési funkciók a háttérszolgáltatásokból, például SSL-leállítás, hitelesítés, IP-címkorlátozások vagy ügyfélsebesség-korlátozás (az úgynevezett szabályozás).

Vannak bemeneti vezérlők a fordított proxykhoz, amelyek közé tartozik az NGINX, a HAProxy, a Traefik és az Azure Application Gateway. Az AKS több felügyelt bejövő lehetőséget is biztosít. A felügyelt NGINX-alapú bejövőforgalom-vezérlő az Application Gateway for Containers alkalmazás-útválasztási bővítményén keresztül. Vagy kiválaszthatja az Istio bejövő átjárót bejövőforgalom-vezérlőként. További információ: Bejövő forgalom az AKS.

A Bejövő erőforrások Kubernetes-objektumait a fejlettebb és sokoldalúbb Kubernetes Gateway API váltotta fel. A bejövőforgalom-vezérlő és az Átjáró API egyaránt Kubernetes-objektum, amelyet forgalomfelügyeleti útválasztáshoz és terheléselosztáshoz használnak. Az általános, kifejező, bővíthető és szerepkör-orientált átjáró API az L4 és L7 útválasztási szabályok Kubernetesben történő meghatározására szolgáló API-k modern készlete.

A bejövőforgalom-vezérlő peremhálózati útválasztóként vagy fordított proxyként működik. A fordított proxykiszolgálók lehetséges szűk keresztmetszetek vagy meghibásodási pontok, ezért javasoljuk, hogy legalább két replikát telepítsen a magas rendelkezésre állás biztosítása érdekében.

Mikor válassza ki a bejövőforgalom-vezérlőket vagy a Gateway API-t?

A bejövő erőforrások a következő használati esetekre alkalmasak:

  • A bejövőforgalom-vezérlők egyszerűen beállíthatók, és kisebb és kevésbé összetett Kubernetes-környezetekhez használhatók, amelyek előnyben részesítik az egyszerű konfigurációt.

  • Ha jelenleg a Kubernetes-fürtön konfigurált bejövő vezérlők hatékonyan felelnek meg a követelményeknek, előfordulhat, hogy nem kell azonnal áttérni a Kubernetes Gateway API-ra.

A Gateway API-t kell használnia:

  • Ha összetett útválasztási konfigurációkkal, forgalomfelosztással és speciális forgalomkezelési stratégiákkal foglalkozik. A Kubernetes Gateway API Útválasztási erőforrásai által biztosított rugalmasság elengedhetetlen.

  • Ha a hálózatkezelési követelményekhez egyéni megoldásokra vagy nem Microsoft-beépülő modulok integrálására van szükség. A Kubernetes Gateway API egyéni erőforrás-definíciókon alapuló megközelítése nagyobb bővíthetőséget biztosít.

Megbízhatóság

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információkért tekintse meg a Megbízhatósági terv felülvizsgálati ellenőrzőlistát.

Mikroszolgáltatások particionálása

Névterek használatával rendszerezheti a fürtön belüli szolgáltatásokat. A Kubernetes-fürtök minden objektuma egy névtérhez tartozik. Ajánlott névterek használatával rendszerezni a fürt erőforrásait.

A névterek segítenek megelőzni az elnevezési ütközéseket. Ha több csapat helyez üzembe mikroszolgáltatásokat ugyanabban a fürtben, akár több száz mikroszolgáltatással, nehéz lesz kezelni, ha mind ugyanabba a névtérbe kerülnek. A névterek a következőket is lehetővé teszik:

  • Alkalmazzon erőforrás-korlátozásokat egy névtérre, hogy a névtérhez rendelt podok teljes készlete ne lépje túl a névtér erőforráskvótáit.

  • A névtér szintjén alkalmazza a szabályzatokat, amelyek közé tartozik a szerepköralapú hozzáférés-vezérlés (RBAC) és a biztonsági szabályzatok.

Ha több csapat fejleszt és helyez üzembe mikroszolgáltatásokat, a névterek kényelmes mechanizmusként használhatók az egyes csapatok által üzembe helyezhető területek szabályozására. Az A fejlesztői csapat például csak az A névtérhez adhat hozzáférést, a B fejlesztőcsapat pedig csak a B névtérhez adhat hozzáférést a Kubernetesen keresztül, RBAC-szabályzatok.

Mikroszolgáltatás-architektúra esetén fontolja meg a mikroszolgáltatások határolókeretes környezetekbe való rendszerezését, és hozzon létre névtereket az egyes határolt környezetekhez. Az "Order Fulfillment" határolt környezethez kapcsolódó mikroszolgáltatások például ugyanabba a névtérbe léphetnek. Másik lehetőségként hozzon létre egy névteret az egyes fejlesztői csapatok számára.

Helyezze a segédprogram-szolgáltatásokat a saját külön névterébe. Üzembe helyezhet például fürtfigyelési eszközöket, például az Elasticsearchet és a Prometheust egy figyelési névtérben.

Állapotminták

A Kubernetes háromféle állapotmintát határoz meg, amelyeket a podok elérhetővé tehetnek:

  • Készültségi mintavétel: jelzi a Kubernetesnek, hogy a pod készen áll-e a kérések elfogadására.

  • Liveness-mintavétel: jelzi a Kubernetesnek, hogy el kell-e távolítani egy podot, és új példányt kell-e elindítani.

  • indítási mintavétel: jelzi a Kubernetesnek, hogy a pod elindult-e.

Ha a mintavételekre gondol, fontos megjegyezni, hogyan működik egy szolgáltatás a Kubernetesben. A szolgáltatásokban van egy olyan címkeválasztó, amely nulla vagy több podkészletnek felel meg. A Kubernetes load balances traffic to the pods to the selector. Csak a sikeres indítású és kifogástalan állapotú podok fogadják a forgalmat. Ha egy tároló összeomlik, a Kubernetes leállítja a podot, és ütemez egy cserét.

Előfordulhat, hogy egy pod nem áll készen a forgalom fogadására, annak ellenére, hogy sikeresen elindult. Előfordulhat például, hogy inicializálási feladatok vannak folyamatban, például amikor a tárolóban futó alkalmazás adatokat tölt be a memóriába, vagy beolvassa a konfigurációs fájlokat. Ezekhez a lassú indítású tárolókhoz használhat indítási mintavételt. Ez a megközelítés segít megakadályozni, hogy a Kubernetes leállítsa őket, mielőtt teljes inicializálásra lenne lehetőségük.

Az élőségi mintavételekkel ellenőrizheti, hogy egy pod fut-e, de nem működik megfelelően, és újra kell-e indítani. Ha például egy tároló HTTP-kéréseket kezel, de hirtelen leáll összeomlás nélkül, az élőségi mintavétel észleli ezt az eseményt, és elindítja a pod újraindítását. Ha beállít egy élőségi mintavételt, az észleli, ha egy tároló nem válaszol, és felszólítja a Kubernetes-t, hogy indítsa újra a podot, ha a tároló ismételten meghiúsul a mintavételen.

A mikroszolgáltatások mintavételeinek tervezésekor vegye figyelembe az alábbi szempontokat.

  • Ha a kód hosszú indítási idővel rendelkezik, fennáll annak a veszélye, hogy egy élőségi mintavétel hibát jelez az indítás előtt. Az élőségi mintavétel indításának késleltetéséhez használja az indítási mintavételt, vagy használja a initialDelaySeconds beállítást az élőség-mintavétellel.

  • Az élőség-mintavétel csak akkor segít, ha a pod újraindítása valószínűleg kifogástalan állapotba állítja vissza. Az élőség-mintavétellel enyhítheti a memóriaszivárgásokat vagy a váratlan holtpontokat, de nincs ok arra, hogy újraindítsa a podot, amely azonnal sikertelen lesz.

  • A függő szolgáltatások ellenőrzéséhez időnként készültségi mintavételeket használnak. Ha például egy pod függ egy adatbázistól, előfordulhat, hogy a mintavétel ellenőrzi az adatbázis-kapcsolatot. Ez a megközelítés azonban váratlan problémákat okozhat. Előfordulhat, hogy egy külső szolgáltatás átmenetileg nem érhető el. Ez az elérhetetlenség miatt a készenlét-mintavétel a szolgáltatás összes podja esetében meghiúsul, ami a terheléselosztásból való eltávolítást eredményezi. Ez az eltávolítás kaszkádolt hibákat okoz a felsőbb rétegben.

    Jobb módszer az újrapróbálkozási kezelés implementálása a szolgáltatáson belül, hogy a szolgáltatás megfelelően helyreálljon az átmeneti hibákból. Alternatív megoldásként az újrapróbálkozással, a hibatűréssel és az áramkör-megszakítókkal az Istio szolgáltatásháló valósítható meg, hogy rugalmas architektúrát hozzon létre, amely képes kezelni a mikroszolgáltatások hibáit.

Erőforrás-korlátozások

Az erőforrás-versengés befolyásolhatja a szolgáltatás rendelkezésre állását. Definiáljon tárolókra vonatkozó erőforráskorlátokat, hogy egyetlen tároló ne tudja túlterhelni a fürt erőforrásait, például a memóriát és a PROCESSZORt. Nem tárolóalapú erőforrások, például szálak vagy hálózati kapcsolatok esetén fontolja meg a válaszfalminta használatát az erőforrások elkülönítéséhez.

Használja erőforráskvótákat a névtérhez engedélyezett összes erőforrás korlátozásához. Ez a korlátozás biztosítja, hogy az előtér ne éheztetheti az erőforrások háttérszolgáltatását, vagy fordítva. Az erőforráskvóták segíthetnek az ugyanazon a fürtön belüli erőforrások több mikroszolgáltatás-fejlesztési csapat számára való lefoglalásában.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információ: Biztonságitervezési felülvizsgálati ellenőrzőlistája.

TLS és SSL-titkosítás

Számos implementációban a bejövőforgalom-vezérlőt ssl-lezáráshoz használják. A bejövőforgalom-vezérlő üzembe helyezésének részeként létre kell hoznia vagy importálnia kell egy Transport Layer Security (TLS) tanúsítványt. Csak önaláírt tanúsítványokat használjon fejlesztési és tesztelési célokra. További információ: Egyéni tartománynév és SSL-tanúsítvány beállítása az alkalmazás útválasztási bővítményével.

Éles számítási feladatok esetén kérje le az aláírt tanúsítványokat megbízható hitelesítésszolgáltatóktól.

Előfordulhat, hogy a tanúsítványokat a szervezet szabályzataitól függően is el kell forgatnia. A Key Vault használatával elforgathatja a mikroszolgáltatások által használt tanúsítványokat. További információ: Tanúsítvány automatikus elforgatásának konfigurálása a Key Vault.

RBAC

Ha egyszerre több csapat fejleszt és helyez üzembe mikroszolgáltatásokat, az AKS RBAC-mechanizmusok részletes vezérlést és szűrést biztosítanak a felhasználói műveletekhez. A Kubernetes RBAC-t vagy az Azure RBAC-t Microsoft Entra-azonosítóval használhatja a fürterőforrásokhoz való hozzáférés szabályozásához. További információ: AKS-hozzáférési és identitásbeállításai.

Hitelesítés és engedélyezés

A mikroszolgáltatások megkövetelhetik, hogy a felhasználók tanúsítványokkal, hitelesítő adatokkal és RBAC-mechanizmusokkal hitelesítsék és engedélyezzék a mikroszolgáltatáshoz való hozzáférést. A Microsoft Entra-azonosítóval OAuth 2.0-jogkivonatok implementálhatók az engedélyezési. Az olyan szolgáltatáshálók, mint például a Istio, olyan engedélyezési és hitelesítési mechanizmusokat is biztosítanak a mikroszolgáltatásokhoz, amelyek magukban foglalják az OAuth-jogkivonatok érvényesítését és a jogkivonatalapú útválasztást. A referencia-implementáció nem terjed ki a mikroszolgáltatás-hitelesítési és engedélyezési forgatókönyvekre.

Titkos kódok kezelése és alkalmazás hitelesítő adatai

Az alkalmazásoknak és szolgáltatásoknak gyakran szükségük van hitelesítő adatokra, amelyek lehetővé teszik számukra, hogy külső szolgáltatásokhoz, például az Azure Storage-hoz vagy az SQL Database-hez csatlakozzanak. A kihívást az jelenti, hogy ezeket a hitelesítő adatokat biztonságban kell tartani, és nem kell kiszivárogtatni őket.

Azure-erőforrások esetén lehetőség szerint használjon felügyelt identitásokat. A felügyelt identitás olyan, mint egy Microsoft Entra-azonosítóban tárolt alkalmazás vagy szolgáltatás egyedi azonosítója. Ezt az identitást használja egy Azure-szolgáltatással való hitelesítéshez. Az alkalmazás vagy szolgáltatás rendelkezik egy szolgáltatásnévvel, amelyet a Microsoft Entra-azonosítóban hoztak létre, és OAuth 2.0-jogkivonatok használatával hitelesít. A folyamaton belül futó kód transzparens módon szerezheti be a jogkivonatot. Ezzel a módszerrel biztosítható, hogy ne kelljen jelszavakat vagy kapcsolati sztringeket tárolnia. Felügyelt identitások használatához Microsoft Entra-identitásokat rendelhet az AKS egyes podjaihoz Microsoft Entra számítási feladatazonosítóhasználatával.

Még felügyelt identitások használata esetén is előfordulhat, hogy néhány hitelesítő adatot vagy más alkalmazáskulcsot kell tárolnia. Ez a tárterület olyan Azure-szolgáltatásokhoz szükséges, amelyek nem támogatják a felügyelt identitásokat, a nem Microsoft-szolgáltatásokat vagy az API-kulcsokat. A titkos kulcsok biztonságosabb tárolásához az alábbi lehetőségeket használhatja:

Egy olyan megoldás használata, mint a Key Vault, számos előnnyel jár, például:

  • A titkos kódok központosított ellenőrzése.
  • Segít biztosítani, hogy minden titkos kód titkosítva legyen.
  • Központosított kulcskezelés.
  • Titkos kódok hozzáférés-vezérlése.
  • Kulcsfontosságú életciklus-kezelés.
  • Könyvvizsgálat.

A referencia-implementáció az Azure Cosmos DB kapcsolati sztringeket és más titkos kulcsokat tárolja a Key Vaultban. A referencia-implementáció egy felügyelt identitást használ a mikroszolgáltatásokhoz a Key Vaultban való hitelesítéshez és a titkos kulcsokhoz való hozzáféréshez.

Tároló és vezénylő biztonsága

Az alábbi ajánlott eljárások segíthetnek a podok és tárolók biztonságossá tételében.

  • Fenyegetések figyelése. A fenyegetések figyelése Microsoft Defender for Containers vagy nem Microsoft-képesség használatával. Ha tárolókat üzemeltet egy virtuális gépen (VM), használja Microsoft Defender for Servers vagy nem Microsoft-képességet. Emellett a naplókat integrálhatja tárolómonitorozási megoldásból az Azure Monitor-ben a Microsoft Sentinel , illetve egy meglévő biztonsági információ- és eseménykezelési (SIEM) megoldásba.

  • Biztonsági rések figyelése. Folyamatosan monitorozza a rendszerképeket és futtatja a tárolókat az ismert biztonsági rések érdekében Microsoft Defender for Cloud vagy egy nem Microsoft-megoldás használatával.

  • A képjavítás automatizálása. A rendszerkép-javítás automatizálásához használja Azure Container Registry-feladatokat, a Container Registry egyik funkcióját. A tárolórendszerkép rétegekből épül fel. Az alaprétegek közé tartoznak az operációs rendszer lemezképei és az alkalmazás-keretrendszer lemezképei, például ASP.NET Core vagy Node.js. Az alaprendszerképeket általában az alkalmazásfejlesztők hozzák létre, és más projektfenntartók is fenntartják őket. Ha ezeket a képeket az adatfolyamon keresztül javítja ki, fontos, hogy frissítse, tesztelje és újra üzembe helyezze a saját rendszerképeit, hogy ne hagyjon ismert biztonsági réseket. Az Azure Container Registry-feladatok segíthetnek a folyamat automatizálásában.

  • A rendszerképeket megbízható privát beállításjegyzékben tárolhatja. A rendszerképek tárolásához használjon megbízható magánregisztrációs adatbázist, például a Tárolóregisztrációs adatbázist vagy a Docker Megbízható beállításjegyzéket. A Kubernetesben érvényesített belépési webhook segítségével biztosíthatja, hogy a podok csak a megbízható beállításjegyzékből kérhessenek le képeket.

  • Alkalmazza a minimális jogosultság elvét. Ne futtasson tárolókat kiemelt módban. A privileged mód tárolóhozzáférést biztosít a gazdagép összes eszközéhez. Ha lehetséges, kerülje a folyamatok gyökérként való futtatását a tárolókban. A tárolók nem biztosítanak teljes elkülönítést biztonsági szempontból, ezért jobb, ha nem kiemelt felhasználóként futtat egy tárolófolyamatot.

Üzembehelyezési CI/CD-szempontok

Fontolja meg a mikroszolgáltatás-architektúra robusztus CI/CD-folyamatának következő céljait:

  • Minden csapat önállóan építheti ki és helyezheti üzembe a tulajdonában lévő szolgáltatásokat anélkül, hogy más csapatokat érintenének vagy zavarnák.

  • Mielőtt üzembe helyeznénk egy szolgáltatás új verzióját az éles környezetben, a rendszer fejlesztési, tesztelési és Q-&A-környezetekben lesz üzembe helyezve ellenőrzés céljából. A minőségi kapukat minden szakaszban érvényesítjük.

  • A szolgáltatás új verziója az előző verzió mellett helyezhető üzembe.

  • Megfelelő hozzáférés-vezérlési szabályzatok vannak érvényben.

  • Tárolóalapú számítási feladatok esetén megbízhat az éles környezetben üzembe helyezett tárolórendszerképekben.

A kihívásokról további információt a CI/CD mikroszolgáltatási architektúrákhoz című témakörben talál.

Az Istio-hoz hasonló szolgáltatásháló használata segíthet a CI-/CD-folyamatokban, például a kanári-telepítésekben, a mikroszolgáltatások A/B-tesztelésében és a százalékos forgalomeloszlással rendelkező szakaszos bevezetésekben.

További információ az egyes javaslatokról és ajánlott eljárásokról: Ci/CD-folyamat létrehozása mikroszolgáltatásokhoz a Kubernetesen az Azure DevOps és a Helmhasználatával.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésére és a működési hatékonyság javítására összpontosít. További információ: Költségoptimalizálásitervezési felülvizsgálati ellenőrzőlistája.

Az Azure díjkalkulátorával megbecsülheti költségeit. További szempontokat a Microsoft Azure Well-Architected Framework Költség című szakaszában olvashat.

Vegye figyelembe az alábbi szempontokat az architektúra egyes szolgáltatásaihoz.

AKS

  • Az ingyenes szintűa Kubernetes-fürt üzembe helyezése, felügyelete és üzemeltetése során az AKS nem jár költségekkel. Csak a Kubernetes-fürt által használt virtuálisgép-példányokért, tárolási és hálózati erőforrásokért kell fizetnie.

  • Fontolja meg podok automatikus horizontális skálázási használatát a mikroszolgáltatások terheléstől függően történő automatikus méretezéséhez vagy horizontális felskálázásához.

  • Konfigurálja fürt automatikus skálázási a csomópontok terheléstől függően történő skálázásához vagy méretezéséhez.

  • Fontolja meg kihasználatlan csomópontok használatát a nem kritikus mikroszolgáltatások üzemeltetéséhez.

  • Tekintse át az AKS költségoptimalizálási ajánlott eljárásait.

  • A szükséges erőforrások költségeinek becsléséhez használja a AKS-kalkulátort.

Azure terheléselosztó

Csak a konfigurált terheléselosztási és kimenő szabályok számáért kell fizetnie. A bejövő hálózati címfordítási szabályok ingyenesek. A Standard Load Balancer nem számít fel óránkénti díjat, ha nincsenek szabályok konfigurálva. További információ: Azure Load Balancer díjszabási.

Azure Pipelines

Ez a referenciaarchitektúra csak az Azure Pipelinest használja. Az Azure egyéni szolgáltatásként biztosítja a folyamatot. A CI/CD esetén minden hónapban 1800 perc ingyenes, Microsoft által üzemeltetett feladat, havonta pedig egy saját üzemeltetésű, korlátlan percekkel rendelkező feladat engedélyezett. A további feladatok több költséget vonnak maga után. További információ: Azure DevOps-szolgáltatások díjszabási.

Azure Monitor

Az Azure Monitor Log Analytics esetében az adatok betöltéséért és megőrzéséért díjat kell fizetnie. További információkért tekintse meg az Azure Monitor díjszabását.

Működési kiválóság

Az Operational Excellence azokat az üzemeltetési folyamatokat fedi le, amelyek üzembe helyeznek egy alkalmazást, és éles környezetben tartják azt. További információ: Működési kiválóságitervezési felülvizsgálati ellenőrzőlistája.

Ez a referenciaarchitektúra Bicep-fájlokat felhőbeli erőforrások és függőségeik kiépítéséhez. Az Azure Pipelines használatával telepítheti ezeket a Bicep-fájlokat, és gyorsan beállíthatja a különböző környezeteket, például az éles forgatókönyvek replikálását. Ez a megközelítés segít a költségek megtakarításában, ha csak szükség esetén épít ki terheléstesztelési környezeteket.

Fontolja meg a számítási feladatok elkülönítési feltételeinek követését a Bicep-fájl strukturálásához. A számítási feladatokat általában a funkciók tetszőleges egységeként definiálják. Létrehozhat például egy külön Bicep-fájlt a fürthöz, majd egy másik fájlt a függő szolgáltatásokhoz. Az Azure DevOps használatával ci/CD-t végezhet számítási feladatok elkülönítésével, mivel az egyes számítási feladatokat a saját csapata társítja és felügyeli.

A forgatókönyv üzembe helyezése

Az architektúra referencia-implementációjának üzembe helyezéséhez kövesse a GitHub-adattár lépéseit. További információ: AKS mikroszolgáltatások referencia implementálási.

Közreműködők

A Microsoft fenntartja ezt a cikket. A következő közreműködők írták ezt a cikket.

Fő szerző:

Egyéb közreműködők:

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések