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

Ez a referenciaarchitektúra az Azure Kubernetes Service-ben (AKS) üzembe helyezett mikroszolgáltatási alkalmazásokat mutatja be. Egy alapszintű AKS-konfigurációt ír le, amely a legtöbb üzembe helyezés kiindulópontja lehet. Ez a cikk a Kubernetes alapszintű ismeretét feltételezi. A cikk elsősorban a mikroszolgáltatás-architektúra AKS-en való futtatásának infrastruktúrájára és DevOps-szempontjaira összpontosít. A mikroszolgáltatások tervezésére vonatkozó útmutatásért lásd : Mikroszolgáltatások létrehozása az Azure-ban.

Az architektúra referencia-implementációja elérhető a GitHubon.

Architektúra

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

Ha egy fejlettebb mikroszolgáltatás-példát szeretne látni, amely az AKS Alapkonfigurációs architektúrára épül, tekintse meg az Advanced Azure Kubernetes Service (AKS) mikroszolgáltatások architektúráját

Workflow

Az architektúra a következőkben leírt összetevőkből áll.

Azure Kubernetes Service (AKS). Az AKS az Azure-felhőben üzemeltetett felügyelt Kubernetes-fürt. Az Azure kezeli a Kubernetes API-szolgáltatást, és csak az ügynökcsomópontokat kell felügyelnie.

Virtuális hálózat. Az AKS alapértelmezés szerint létrehoz egy virtuális hálózatot, amelybe az ügynökcsomópontok csatlakoznak. A virtuális hálózatot először speciálisabb forgatókönyvekhez hozhatja létre, így szabályozhatja például az alhálózat konfigurálását, a helyszíni kapcsolatot és az IP-címzést. További információ: Speciális hálózatkezelés konfigurálása az Azure Kubernetes Service-ben (AKS).

Bejövő forgalom. Egy bejövő kiszolgáló HTTP-útvonalakat tesz elérhetővé a fürtön belüli szolgáltatások számára. További információkért tekintse meg az API Gateway alábbi szakaszát.

Azure Load Balancer. Az AKS-fürt létrehozása után a fürt készen áll a terheléselosztó használatára. Ezután az NGINX szolgáltatás üzembe helyezése után a terheléselosztó egy új nyilvános IP-címmel lesz konfigurálva, amely a bejövőforgalom-vezérlő elé kerül. Így a terheléselosztó az internetes forgalmat a bejövő forgalomhoz irányítja.

Külső adattárak. A mikroszolgáltatások általában állapot nélküliek és írási állapotot jelentenek külső adattárakba, például az Azure SQL Database-be vagy az Azure Cosmos DB-be.

Microsoft Entra-azonosító. Az AKS Microsoft Entra-identitással hoz létre és kezel más Azure-erőforrásokat, például azure-terheléselosztókat. A Microsoft Entra-azonosító az ügyfélalkalmazásokban a felhasználói hitelesítéshez is ajánlott.

Azure Container Registry. A Tárolóregisztrációs adatbázis használatával privát Docker-rendszerképeket tárolhat, amelyek a fürtben vannak üzembe helyezve. Az AKS a Tárolóregisztrációs adatbázissal a Microsoft Entra-identitásával hitelesíthető. Az AKS-hez nem szükséges az Azure Container Registry. Használhat más tárolóregisztrációs adatbázisokat is, például a Docker Hubot. Csak győződjön meg arról, hogy a tárolóregisztrációs adatbázis megfelel vagy meghaladja a számítási feladathoz tartozó szolgáltatásiszint-szerződést (SLA).

Azure Pipelines. Az Azure Pipelines az Azure DevOps Services része, és automatizált buildeket, teszteket és üzembe helyezéseket futtat. Külső CI-/CD-megoldásokat is használhat, például a Jenkinst.

Helm. A Helm a Kubernetes csomagkezelője, aMellyel a Kubernetes-objektumokat egyetlen egységbe csomagolhatja és általánosíthatja, amely közzétehető, üzembe helyezhető, verziószámozható és frissíthető.

Azure Monitor. Az Azure Monitor metrikákat és naplókat, alkalmazás telemetriákat és platformmetrikákat gyűjt és tárol az Azure-szolgáltatásokhoz. Ezekkel az adatokkal figyelheti az alkalmazást, riasztásokat, irányítópultokat állíthat be, és elvégezheti a hibák kiváltó okainak elemzését. Az Azure Monitor integrálható az AKS-sel a vezérlők, csomópontok és tárolók metrikáinak gyűjtéséhez.

Considerations

Tervezés

Ez a referenciaarchitektúra a mikroszolgáltatás-architektúrákra összpontosít, bár 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 szolgáltatásnak mindig elérhetőnek kell lennie, még akkor is, ha a podok mozognak. A Kubernetes Service objektum természetes módja a mikroszolgáltatások modellezésének a Kubernetesben.

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. Fordított proxyként működik, amely az ügyfelektől a mikroszolgáltatásokhoz irányuló kéréseket irányítja át. Emellett különböző horizontális feladatokat is elvégezhet, például hitelesítést, SSL-lezárást és sebességkorlátozást. For more information, see:

• API-átjárók használata mikroszolgáltatásokban
• Átjárótechnológia kiválasztása

A Kubernetesben az API-átjárók funkcióit elsősorban egy bejövőforgalom-vezérlő kezeli. A szempontokat a bejövő forgalom szakasz ismerteti.

Adattárolás

Mikroszolgáltatás-architektúrában a szolgáltatások nem oszthatnak meg adattárolási megoldásokat. 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, ami akkor fordulhat elő, ha a szolgáltatások azonos mögöttes adatsémákat használnak. Emellett 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 tervezése: Adatvezérek.

Kerülje az állandó adatok tárolását a helyi fürttárolóban, mert az az adatokat a csomóponthoz köti. Ehelyett használjon külső szolgáltatást, például az Azure 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 Disks vagy az Azure Files használatával.

További információkért tekintse meg az Azure Kubernetes Service-ben elérhető alkalmazások tárolási lehetőségeit.

Szolgáltatásobjektum

A Kubernetes Service-objektum olyan képességeket biztosít, amelyek megfelelnek a szolgáltatás felderíthetőségére vonatkozó mikroszolgáltatási követelményeknek:

• IP-cím. A szolgáltatásobjektum statikus belső IP-címet biztosít a podok egy csoportjához (ReplicaSet). A podok létrehozásakor vagy áthelyezésekor a szolgáltatás mindig elérhető ezen a belső IP-címen.

• Terheléselosztás. A szolgáltatás IP-címére küldött forgalom terheléselosztásban van a podok között.

• Szolgáltatásfelderítés. A szolgáltatásokat a Kubernetes DNS-szolgáltatás rendeli hozzá belső DNS-bejegyzésekhez. Ez azt jelenti, hogy az API-átjáró meghívhat egy háttérszolgáltatást a DNS-név használatával. Ugyanez a mechanizmus használható a szolgáltatásközi kommunikációhoz is. A DNS-bejegyzések névtér szerint vannak rendszerezve, így ha a névterek a határolt környezeteknek felelnek meg, akkor a szolgáltatás DNS-neve természetesen megfeleltethető az alkalmazástartománynak.

Az alábbi ábra a szolgáltatások és podok közötti fogalmi kapcsolatot mutatja be. A végpont IP-címeinek és portjainak tényleges leképezését a Kube-proxy, a Kubernetes hálózati proxy végzi.

Ingress

A Kubernetesben a bejövőforgalom-vezérlő implementálhatja az API-átjáró mintáját. Ebben az esetben a bejövő ésbejövőforgalom-vezérlő együttesen biztosítja az alábbi funkciókat:

• Az ügyfélkérések átirányítása a megfelelő háttérszolgá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érrendszer 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-korlátozások vagy ügyfélsebesség-korlátozás (szabályozás).

A bejövő forgalom elvonja a proxykiszolgáló konfigurációs beállításait. Szüksége van egy bejövőforgalom-vezérlőre is, amely biztosítja a bejövő forgalom mögöttes implementációját. Többek között Nginx, HAProxy, Traefik és Azure-alkalmazás Gateway bejövőforgalom-vezérlői is vannak.

A bejövő forgalom erőforrása különböző technológiákkal teljesíthető. Az együttműködéshez a fürt bejövőforgalom-vezérlőjeként kell üzembe helyezni őket. 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 mindig telepítsen legalább két replikát a magas rendelkezésre állás érdekében.

A proxykiszolgáló konfigurálása gyakran összetett fájlokat igényel, amelyeket nehéz lehet finomhangolni, ha nem szakértő. Így a bejövőforgalom-vezérlő kellemes absztrakciót biztosít. A bejövőforgalom-vezérlő a Kubernetes API-hoz is hozzáfér, így intelligens döntéseket hozhat az útválasztásról és a terheléselosztásról. Az Nginx bejövőforgalom-vezérlője például áthalad a kube-proxy hálózati proxyján.

Ha azonban teljes körű vezérlésre van szüksége a beállítások felett, érdemes lehet megkerülni ezt az absztrakciót, és manuálisan konfigurálni a proxykiszolgálót. További információ: Nginx vagy HAProxy üzembe helyezése a Kubernetesben.

Az Azure-beli terheléselosztási szolgáltatásokról további információt az Azure terheléselosztási lehetőségeinek áttekintése című témakörben talál.

TLS/SSL-titkosítás

A gyakori implementációkban a bejövőforgalom-vezérlőt az SSL-leállításhoz használják. Ezért a bejövőforgalom-vezérlő üzembe helyezésének részeként létre kell hoznia egy TLS-tanúsítványt. Csak önaláírt tanúsítványokat használjon fejlesztési/tesztelési célokra. További információ: HTTPS bejövőforgalom-vezérlő létrehozása és saját TLS-tanúsítványok használata az Azure Kubernetes Service-ben (AKS).

Éles számítási feladatok esetén kérje le az aláírt tanúsítványokat a megbízható hitelesítésszolgáltatóktól. A Let's Encrypt-tanúsítványok létrehozásával és konfigurálásával kapcsolatos információkért lásd: Bejövőforgalom-vezérlő létrehozása statikus nyilvános IP-címmel az Azure Kubernetes Service-ben (AKS).

Előfordulhat, hogy a tanúsítványokat a szervezet szabályzatainak megfelelően kell elforgatnia. További információ: Tanúsítványok elforgatása az Azure Kubernetes Service-ben (AKS).

Névterek

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. Ha új objektumot hoz létre, alapértelmezés szerint a default névtérbe kerül. Célszerű azonban olyan névtereket létrehozni, amelyek leíróbbak a fürt erőforrásainak rendszerezéséhez.

Először is 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. Emellett a névterek lehetővé teszik a következőt:

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

• Szabályzatok alkalmazása névtérszinten, beleértve az RBAC-t és a biztonsági szabályzatokat.

Mikroszolgáltatás-architektúra esetén a mikroszolgáltatások határolókeretes környezetekbe való rendszerezését és az egyes határolt környezetek névtereinek létrehozását mérlegelve. Az "Order Fulfillment" határolt környezethez kapcsolódó mikroszolgáltatások például ugyanabba a névtérbe kerülhetnek. 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 helyezheti például az Elasticsearch vagy a Prometheus fürtök figyelését, vagy a Helm Tillerét.

Állapotminták

A Kubernetes kétféle állapotadat-mintavételt 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.

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

A mintavételek használatakor hasznos felidézni, hogyan működik egy szolgáltatás a Kubernetesben. A szolgáltatás címkeválasztóval rendelkezik, amely megfelel a (nulla vagy több) podoknak. A Kubernetes load balances traffic to the pods to the selector. Csak a sikeresen elindult és kifogástalan állapotú podok fogadják a forgalmat. Ha egy tároló összeomlik, a Kubernetes megöli 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 a pod sikeresen elindult. Lehetnek például inicializálási feladatok, ahol a tárolóban futó alkalmazás betölti a dolgokat a memóriába, vagy beolvassa a konfigurációs adatokat. Annak jelzéséhez, hogy a pod kifogástalan állapotú, de nem áll készen a forgalom fogadására, adjon meg egy készültségi mintavételt.

A liveness-mintavételek kezelik azt az esetet, amikor egy pod még fut, de nem kifogástalan, és újra kell hasznosítani. Tegyük fel például, hogy egy tároló HTTP-kéréseket szolgál ki, de valamilyen okból lefagy. A tároló nem összeomlik, de leállt a kérések kiszolgálása. Ha HTTP-élőségi mintavételt határoz meg, a mintavétel nem válaszol, és tájékoztatja a Kubernetes-t a pod újraindításáról.

Íme néhány szempont a mintavételek tervezésekor:

• Ha a kód hosszú indítási idővel rendelkezik, fennáll annak a veszélye, hogy az élőség-mintavétel hibajelentést fog jelenteni az indítás befejezése előtt. A mintavételi hiba megelőzéséhez használja a initialDelaySeconds beállítást, amely késlelteti a mintavétel indítását.

• 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. A memóriaszivárgások vagy váratlan holtpontok elleni védekezéshez használhat élőségi mintavételt, de nincs értelme újraindítani egy 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 valamilyen okból átmenetileg nem érhető el. Ez azt eredményezi, hogy a készenlét-mintavétel meghiúsul a szolgáltatás összes podjához, így az összeset eltávolítja a terheléselosztásból, és így 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.

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 erőforrás-korlátozásokat a tárolókhoz, hogy egyetlen tároló ne terhelhesse túl a fürt erőforrásait (memória és CPU). Nem tárolóalapú erőforrások, például szálak vagy hálózati kapcsolatok esetén fontolja meg az erőforrások elkülönítését a Válaszfalminta használatával.

Erőforráskvótákkal korlátozhatja a névtérhez engedélyezett összes erőforrást. Így az előtér nem tudja éhezni az erőforrások háttérszolgáltatását, vagy fordítva.

Biztonság

Szerepköralapú hozzáférés-vezérlés (RBAC)

A Kubernetes és az Azure egyaránt rendelkezik szerepköralapú hozzáférés-vezérlési (RBAC) mechanizmusokkal:

• Az Azure RBAC szabályozza az Erőforrásokhoz való hozzáférést az Azure-ban, beleértve az új Azure-erőforrások létrehozásának lehetőségét is. Az engedélyek felhasználókhoz, csoportokhoz vagy szolgáltatásnevekhez rendelhetők hozzá. (A szolgáltatásnév az alkalmazások által használt biztonsági identitás.)

• A Kubernetes RBAC szabályozza a Kubernetes API engedélyeit. A podok létrehozása és a podok listázása például olyan műveletek, amelyek a Kubernetes RBAC-n keresztül engedélyezhetők (vagy megtagadhatók) a felhasználók számára. Ha Kubernetes-engedélyeket szeretne hozzárendelni a felhasználókhoz, szerepköröket és szerepkör-kötéseket kell létrehoznia:

  • A szerepkör olyan engedélyek készlete, amelyek egy névtéren belül érvényesek. Az engedélyek az erőforrásokon (podokon, üzemelő példányokon stb.) lévő igeként (lekérés, frissítés, létrehozás, törlés) vannak definiálva.

  • A RoleBinding felhasználókat vagy csoportokat rendel egy szerepkörhöz.

  • Van egy ClusterRole objektum is, amely olyan, mint egy szerepkör, de a teljes fürtre vonatkozik az összes névtérben. Ha felhasználókat vagy csoportokat szeretne hozzárendelni egy ClusterRole-hoz, hozzon létre egy ClusterRoleBindinget.

Az AKS integrálja ezt a két RBAC-mechanizmust. AKS-fürt létrehozásakor konfigurálhatja úgy, hogy a Microsoft Entra ID-t használja a felhasználói hitelesítéshez. A beállítással kapcsolatos részletekért lásd : Microsoft Entra ID integrálása az Azure Kubernetes Service-vel.

A konfigurálás után a Kubernetes API-t (például a kubectlen keresztül) elérni kívánó felhasználóknak be kell jelentkezniük a Microsoft Entra hitelesítő adataikkal.

Alapértelmezés szerint egy Microsoft Entra-felhasználónak nincs hozzáférése a fürthöz. A hozzáférés biztosításához a fürt rendszergazdája olyan RoleBindings-eket hoz létre, amelyek Microsoft Entra-felhasználókra vagy -csoportokra hivatkoznak. Ha egy felhasználó nem rendelkezik engedélyekkel egy adott művelethez, az sikertelen lesz.

Ha a felhasználók alapértelmezés szerint nem rendelkeznek hozzáféréssel, hogyan hozhatja létre először a szerepkör-kötéseket a fürt rendszergazdája? Az AKS-fürtöknek valójában két hitelesítő adattípusuk van a Kubernetes API-kiszolgáló meghívásához: fürtfelhasználó és fürtadminisztrátor. A fürt rendszergazdai hitelesítő adatai teljes hozzáférést biztosítanak a fürthöz. Az Azure CLI-parancs az aks get-credentials --admin letölti a fürt rendszergazdai hitelesítő adatait, és menti őket a kubeconfig fájlba. A fürt rendszergazdája ezt a kubeconfigot használhatja szerepkörök és szerepkör-kötések létrehozásához.

A Kubernetes-fürtszerepkör és a RoleBinding-objektumok natív kezelése helyett célszerű az Azure RBAC-t használni a Kubernetes-engedélyezéshez. Így egységes felügyelet és hozzáférés-vezérlés érhető el az Azure-erőforrások, az AKS és a Kubernetes-erőforrások között. Ezek az Azure RBAC-szerepkör-hozzárendelések a fürtben lévő fürtöket vagy névtereket célozhatják meg a részletesebb hozzáférés-vezérlés érdekében. Az Azure RBAC korlátozott számú alapértelmezett engedélyt támogat, és kombinálhatja a szerepkörök és szerepkörbindingek kezelésére szolgáló natív Kubernetes-mechanizmussal a speciális vagy részletesebb hozzáférési minták támogatásához. Ha engedélyezve van, a Microsoft Entra-tagokat kizárólag az Azure RBAC érvényesíti, míg a kubernetes rendszeres felhasználóit és szolgáltatásfiókjait kizárólag a Kubernetes RBAC érvényesíti.

Mivel a fürt rendszergazdai hitelesítő adatai olyan hatékonyak, az Azure RBAC használatával korlátozhatja a hozzáférésüket:

• Az "Azure Kubernetes Service-fürt Rendszergazda szerepkör" engedéllyel rendelkezik a fürt rendszergazdai hitelesítő adatainak letöltéséhez. Ehhez a szerepkörhöz csak fürtgazdák rendelhetők hozzá.

• Az "Azure Kubernetes Service-fürt felhasználói szerepköre" engedéllyel rendelkezik a fürt felhasználói hitelesítő adatainak letöltéséhez. Ehhez a szerepkörhöz nem rendszergazdai felhasználók rendelhetők hozzá. Ez a szerepkör nem ad külön engedélyeket a kubernetes-erőforrásokhoz a fürtön belül – csak lehetővé teszi a felhasználó számára, hogy csatlakozzon az API-kiszolgálóhoz.

Az RBAC-szabályzatok definiálásakor (a Kubernetes és az Azure egyaránt) gondolja át a szervezet szerepköreit:

• Ki hozhat létre vagy törölhet AKS-fürtöt, és töltheti le a rendszergazdai hitelesítő adatokat?
• Ki felügyelhet fürtöt?
• Ki hozhat létre vagy frissíthet erőforrásokat egy névtérben?

Célszerű a Kubernetes RBAC-engedélyeket névtér alapján hatókörbe helyezni, a ClusterRoles és a ClusterRoleBindings helyett szerepkörök és szerepkörbindingek használatával.

Végül felmerül a kérdés, hogy az AKS-fürtnek milyen engedélyekkel kell létrehoznia és kezelnie az Azure-erőforrásokat, például a terheléselosztókat, a hálózatkezelést vagy a tárolást. Az Azure API-kkal való hitelesítéshez a fürt egy Microsoft Entra szolgáltatásnevet használ. Ha nem ad meg egyszerű szolgáltatást a fürt létrehozásakor, a rendszer automatikusan létrehoz egyet. Érdemes azonban először létrehozni a szolgáltatásnevet, és hozzárendelni hozzá a minimális RBAC-engedélyeket. További információ: Szolgáltatásnevek az Azure Kubernetes Service-lel.

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.

Az Azure-erőforrások esetében az egyik lehetőség a felügyelt identitások használata. A felügyelt identitás fogalma az, hogy egy alkalmazás vagy szolgáltatás rendelkezik a Microsoft Entra-azonosítóban tárolt identitással, és 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 ID-ban hoztak létre, és OAuth 2.0-jogkivonatokkal hitelesít. A végrehajtási folyamat kódja transzparens módon lekérheti a használni kívánt jogkivonatot. Így nem kell jelszavakat vagy kapcsolati sztring tárolnia. A felügyelt identitásokat az AKS-ben úgy használhatja, hogy Microsoft Entra-identitásokat rendel az egyes podokhoz Microsoft Entra Számítási feladat ID (előzetes verzió) használatával.

Jelenleg nem minden Azure-szolgáltatás támogatja a felügyelt identitásokkal történő hitelesítést. A listát a Microsoft Entra-hitelesítést támogató Azure-szolgáltatásokban találja.

Még a felügyelt identitások esetében is valószínűleg el kell tárolnia néhány hitelesítő adatot vagy más alkalmazáskulcsot, akár olyan Azure-szolgáltatások esetében, amelyek nem támogatják a felügyelt identitásokat, a külső szolgáltatásokat, az API-kulcsokat stb. Az alábbiakban néhány lehetőséget talál a titkos kulcsok biztonságos tárolására:

• Azure Key Vault. Az AKS-ben kötetként csatlakoztathat egy vagy több titkos kulcsot a Key Vaultból. A kötet beolvassa a titkos kulcsokat a Key Vaultból. A pod ezután ugyanúgy elolvashatja a titkos kulcsokat, mint egy normál kötetet. További információ: Az Azure Key Vault-szolgáltató használata titkos kulcstár csi-illesztőprogramjának használata egy AKS-fürtben.

  A pod egy számítási feladat identitásával vagy egy felhasználó vagy rendszer által hozzárendelt felügyelt identitás használatával hitelesíti magát. További szempontokért tekintse meg az Azure Key Vault-szolgáltató titkos kulcstároló csi-illesztőprogramhoz való hozzáféréséhez szükséges identitást.

• HashiCorp Vault. A Kubernetes-alkalmazások a Microsoft Entra által felügyelt identitásokkal hitelesíthetik a HashiCorp Vaultot. Lásd: A HashiCorp Vault a Microsoft Entra-azonosítót beszéli. A Tárolót üzembe helyezheti a Kubernetesben, érdemes lehet az alkalmazásfürttől külön dedikált fürtön futtatni.

• Kubernetes-titkok. Egy másik lehetőség egyszerűen a Kubernetes titkos kulcsainak használata. Ez a beállítás a legegyszerűbben konfigurálható, de van néhány kihívása. A titkos kulcsokat az ETCD tárolja, amely egy elosztott kulcs-érték tároló. Az AKS inaktív állapotban titkosítja az etcd-t. A Microsoft kezeli a titkosítási kulcsokat.

Egy olyan rendszer használata, mint a HashiCorp Vault vagy az Azure Key Vault, számos előnnyel jár, például:

• A titkos kódok központosított ellenőrzése.
• Annak biztosítása, hogy az összes titkos kód titkosítva legyen.
• Központosított kulcskezelés.
• Titkos kódok hozzáférés-vezérlése.
• Naplózás

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

A podok és tárolók biztonságossá tételéhez ajánlott eljárások:

• Veszélyforrások monitorozása: A fenyegetések figyelése a Microsoft Defender for Containers (vagy külső féltől származó képességek) használatával. Ha tárolókat üzemeltet egy virtuális gépen, használja a Microsoft Defendert kiszolgálókhoz vagy egy külső féltől származó képességet. Emellett a naplókat integrálhatja az Azure Monitor tárolómonitorozási megoldásából a Microsoft Sentinelbe vagy egy meglévő SIEM-megoldásba.

• Sebezhetőségek monitorozása: Folyamatosan monitorozza a rendszerképeket és tárolókat futtat az ismert biztonsági rések érdekében az Azure Marketplace-en keresztül elérhető Felhőhöz készült Microsoft Defender vagy külső megoldás használatával.

• A képjavítás automatizálása az Azure Container Registry egyik funkciója, az ACR Tasks használatával. A tárolórendszerkép rétegekből épül fel. Az alaprétegek közé tartoznak az operációsrendszer-rendszerképek é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 tartják karban. Ha ezeket a képeket az adatfolyamon keresztül javítja ki, fontos frissíteni, tesztelni és újra üzembe helyezni a saját lemezképeit, hogy ne hagyjon ismert biztonsági réseket. Az ACR-feladatok segíthetnek a folyamat automatizálásában.

• A rendszerképeket egy megbízható magánregisztrációs adatbázisban , például az Azure Container Registryben vagy a Docker Megbízható beállításjegyzékben tárolhatja. A Kubernetes-ben érvényesített belépési webhookokkal biztosíthatja, hogy a podok csak a megbízható beállításjegyzékből tudjanak lemezképeket lekérni.

• A Minimális jogosultság elve alkalmazása

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

DevOps

Ez a referenciaarchitektúra egy Azure Resource Manager-sablont biztosít a felhőerőforrások és függőségei kiépítéséhez. Az [Azure Resource Manager-sablonok][arm-sablon] használatával az Azure DevOps Services használatával percek alatt kiépítheti a különböző környezeteket, például replikálhatja az éles forgatókönyveket. Ez lehetővé teszi a költségmegtakarítást és a terheléstesztelési környezet kiépítését, ha szükséges.

Fontolja meg a számítási feladatok elkülönítési feltételeinek követését az ARM-sablon strukturálásához, a számítási feladat általában egy tetszőleges funkcióegységként van definiálva; például külön sablont használhat a fürthöz, majd a függő szolgáltatásokhoz. A számítási feladatok elkülönítése lehetővé teszi a DevOps számára a folyamatos integrációt és a folyamatos teljesítést (CI/CD), mivel minden számítási feladatot a megfelelő DevOps-csapat társít és kezel.

Üzembe helyezési (CI/CD) szempontok

Íme néhány cél egy robusztus CI/CD-folyamathoz egy mikroszolgáltatás-architektúra esetében:

• 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, üzembe kell helyezni a fejlesztési/tesztelési/minőségbiztosítási környezetekben 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.

Konkrét javaslatokért és ajánlott eljárásokért lásd a CI/CD-t a Kubernetes mikroszolgáltatásaival kapcsolatban.

Költségoptimalizálás

Az Azure díjkalkulátorával megbecsülheti költségeit. Egyéb szempontokat a Microsoft Azure Well-Architected Framework Költség szakaszában ismertetünk.

Az alábbi szempontokat érdemes figyelembe venni az architektúra egyes szolgáltatásaival kapcsolatban.

Azure Kubernetes Service (AKS)

Az AKS nem jár költségekkel a Kubernetes-fürt üzembe helyezése, felügyelete és üzemeltetése során. Csak a Kubernetes-fürt által felhasznált virtuális gépek példányaiért, tárolási és hálózati erőforrásaiért kell fizetnie.

A szükséges erőforrások költségét a Container Service díjkalkulátora segítségével becsülheti fel.

Azure Load balancer

Csak a konfigurált terheléselosztási és kimenő szabályok számáért kell fizetnie. A bejövő NAT-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ókért lásd az Azure Load Balancer díjszabását.

Azure Pipelines

Ez a referenciaarchitektúra csak az Azure Pipelinest használja. Az Azure egyéni szolgáltatásként kínálja az Azure Pipeline-t. Havonta 1800 percet vesz igénybe a CI/CD-n, és egy saját üzemeltetésű, havi korlátlan percdíjú feladatot, a további feladatokért díjakat kell fizetnie. További információkért tekintse meg az Azure DevOps Services díjszabását.

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.

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.

Következő lépések

• Szolgáltatásnevek az Azure Kubernetes Service-vel
• Microsoft Defender tárolókhoz
• Microsoft Defender kiszolgálókhoz
• Tárolómonitorozási megoldás az Azure Monitorban
• Microsoft Sentinel vagy egy meglévő SIEM-megoldás.
• Felhőhöz készült Microsoft Defender vagy egy külső megoldás, amely az Azure Marketplace-en keresztül érhető el.
• ACR-feladatok

Kapcsolódó erőforrások

• Egy fejlettebb mikroszolgáltatás-példán keresztüli munkához lásd : Advanced Azure Kubernetes Service (AKS) mikroszolgáltatás-architektúra
• Az architektúra monitorozásáról további információt az Azure Kubernetes Service (AKS) mikroszolgáltatási architektúráinak monitorozása című témakörben talál.
• Az alkalmazás teljesítményének mérését a teljesítmény finomhangolási forgatókönyvében találhatja meg: Elosztott üzleti tranzakciók.
• CI/CD a mikroszolgáltatási architektúrákhoz
• CI/CD mikroszolgáltatásokhoz a Kubernetesen