Mikroszolgáltatás-architektúra a Azure Kubernetes Service

Ez a referenciaarchitektúra egy Azure Kubernetes Service (AKS) szolgáltatásban üzembe helyezett mikroszolgáltatás-alkalmazást mutat 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ával kapcsolatos infrastruktúrával és DevOps-szempontokkal foglalkozik. 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 GitHub érhető el.

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

Ha az AKS Alapkonfigurációs architektúrára épülő fejlettebb mikroszolgáltatás-példát szeretne látni, tekintse meg a Speciális Azure Kubernetes Service (AKS) mikroszolgáltatás-architektúrát

Összetevők

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

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

Virtuális hálózat. Az AKS alapértelmezés szerint létrehoz egy virtuális hálózatot, amelyhez ügynökcsomópontok csatlakoznak. A virtuális hálózatot először speciálisabb forgatókönyvekhez hozhatja létre, így többek között az alhálózati konfigurációt, a helyszíni kapcsolatot és az IP-címzést szabályozhatja. További információt a Azure Kubernetes Service (AKS) speciális hálózatkezelésének konfigurálása című témakörben talál.

Bejövő forgalom. A bejövőforgalom-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 ALÁBBI API Gateway című szakaszt.

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 állapotok külső adattárakba, például Azure SQL Database vagy Cosmos DB-be.

Azure Active Directory. Az AKS egy Azure Active Directory (Azure AD) identitással hoz létre és kezel más Azure-erőforrásokat, például azure-terheléselosztókat. Azure AD az ügyfélalkalmazások felhasználói hitelesítéséhez 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ürtön vannak üzembe helyezve. Az AKS hitelesítést végezhet a Container Registryben annak Azure AD identitásával. Vegye figyelembe, hogy az AKS nem igényel Azure Container Registry. Használhat más tárolóregisztrációs adatbázisokat is, például Docker Hub.

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ástelemetria- é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, hogy metrikákat gyűjtsön a vezérlőkből, csomópontokból és tárolókból.

Kialakítási szempontok

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éssel észlelhetők. A szolgáltatásnak mindig elérhetőnek kell lennie 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, és a kéréseket az ügyfelektől a mikroszolgáltatásokhoz irányítja. Emellett különböző átfogó feladatokat is végrehajthat, például hitelesítést, SSL-leállítást és sebességkorlátozást. További információkért lásd:

• 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 szakaszban ismertetjük.

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 adatok elkülönítése 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ákon osztoznak. 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: Adatokkal kapcsolatos szempontok.

Kerülje az állandó adatok helyi fürttárolóban való tárolását, mert az az adatokat a csomóponthoz köti. Ehelyett használjon külső szolgáltatást, például Azure SQL Database vagy Cosmos DB-t. Egy másik lehetőség az állandó adatkötet csatlakoztatása egy megoldáshoz az Azure Disks vagy Azure Files használatával.

További információ: Storage Azure Kubernetes Service alkalmazásbeállításai.

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 egy podcsoporthoz (ReplicaSet). A podok létrehozása vagy áthelyezése során 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ása a podok között történik.

• 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ások közötti kommunikációhoz is. A DNS-bejegyzések névtér szerint vannak rendszerezve, így ha a névterek a kötött környezeteknek felelnek meg, akkor a szolgáltatás DNS-neve természetesen le lesz képezve az alkalmazás tartományára.

Az alábbi ábra a szolgáltatások és podok fogalmi viszonyát 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.

Bejövő forgalom

A Kubernetesben a bejövőforgalom-vezérlő implementálhatja az API-átjáró mintáját. Ebben az esetben a bejövőforgalom - és bejö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 egyetlen végpontot biztosít az ügyfelek számára, és segít elkülöníteni az ügyfeleket a szolgáltatásoktó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ég van egy bejövőforgalom-vezérlőre is, amely biztosítja a bejövő forgalom mögöttes megvalósítását. Többek között Nginx, HAProxy, Traefik és Azure Application Gateway bejövőforgalom-vezérlők is elérhetők.

A bejövőforgalom-erőforrás különböző technológiákkal teljesíthető. A közös munkához 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ó egy lehetséges szűk keresztmetszet vagy egy meghibásodási pont, ezért mindig helyezzen üzembe 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, amelyek nem szakértőként nehezen hangolhatók. Tehát a bejövőforgalom-vezérlő szép 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ással és a terheléselosztással kapcsolatban. Az Nginx bejövőforgalom-vezérlő például megkerüli a kube-proxy hálózati proxyt.

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ó: Az Nginx vagy a HAProxy üzembe helyezése a Kubernetesben.

Az AKS-hez Azure Application Gateway is használhatja a Application Gateway bejövőforgalom-vezérlőt. Ehhez a beállításhoz engedélyezni kell a CNI-hálózatkezelést az AKS-fürt konfigurálásakor, mivel Application Gateway az AKS virtuális hálózatának alhálózatán van üzembe helyezve. Azure Application Gateway 7. rétegbeli útválasztást és SSL-lezárásokat hajthat végre. Beépített webalkalmazási tűzfalat (WAF) is támogat.

További információ az Azure terheléselosztási szolgáltatásairól: Az Azure terheléselosztási lehetőségeinek áttekintése.

TLS/SSL-titkosítás

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

Éles számítási feladatok esetén szerezze be a megbízható hitelesítésszolgáltatóktól (CA) származó aláírt tanúsítványokat. 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 a Azure Kubernetes Service (AKS) szolgáltatásban.

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

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. Amikor új objektumot hoz létre, az alapértelmezés szerint a default névtérbe kerül. Érdemes 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 is, nehéz lesz kezelni, ha mind ugyanabba a névtérbe kerülnek. Emellett a névterek a következőt teszik lehetővé:

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

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

Mikroszolgáltatás-architektúra esetén a mikroszolgáltatások körülhatárolt környezetekbe való rendszerezését és az egyes körülhatárolt környezetekhez tartozó névterek létrehozását fontolgatja. Az "Order Fulfillment" körülhatárolt környezethez kapcsolódó összes mikroszolgáltatás például ugyanabba a névtérbe kerülhet. 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 alkalmazást a fürtfigyeléshez, 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észenlét-mintavétel: Jelzi a Kubernetesnek, hogy a pod készen áll-e a kérések fogadására.

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

A mintavételek használatakor hasznos felidézni, hogyan működik egy szolgáltatás a Kubernetesben. A szolgáltatás rendelkezik egy olyan címkeválasztóval, amely megfelel egy (nulla vagy több) podkészletnek. A Kubernetes terheléselosztást hoz létre a választóval egyező podok felé. Csak azok a podok fogadják a forgalmat, amelyek sikeresen elindultak, és kifogástalan állapotban vannak. Ha egy tároló összeomlik, a Kubernetes leállítja a podot, és cserét ütemez.

Előfordulhat, hogy egy pod nem áll készen a forgalom fogadására, annak ellenére, hogy a pod sikeresen elindult. Előfordulhatnak például inicializálási feladatok, amikor 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 egy pod kifogástalan állapotú, de nem áll készen a forgalom fogadására, adjon meg egy készenlét-mintavételt.

Az élettartam-mintavételek kezelik azt az esetet, amikor egy pod még fut, de nem kifogástalan állapotú, é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-élettartam-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 élességi mintavétel hibát fog jelenteni az indítás befejezése előtt. Ennek elkerülése érdekében használja a initialDelaySeconds beállítást, amely késlelteti a mintavétel indítását.

• Az élettartam-mintavétel csak akkor segít, ha a pod újraindítása valószínűleg kifogástalan állapotba állítja vissza. Az élességi mintavétellel elháríthatja a memóriavesztést vagy a váratlan holtpontokat, de nincs értelme újraindítani egy olyan podot, amely azonnal ismét meghibásodik.

• 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, a mintavétel ellenőrizheti 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 a szolgáltatásban lévő összes pod esetében sikertelen lesz, ezért az összes pod el lesz távolítva a terheléselosztásból, és így kaszkádolt hibákat eredményez a felsőbb rétegben. Jobb módszer az újrapróbálkozások kezelése a szolgáltatáson belül, hogy a szolgáltatás megfelelően helyreálljon az átmeneti hibák után.

Erőforrás-korlátozások

Az erőforrás-versengés hatással lehet egy szolgáltatás rendelkezésre állására. 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 a válaszfalminta használatát az erőforrások elkülönítéséhez.

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

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

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

• Az Azure RBAC szabályozza az Azure-beli erőforrásokhoz való hozzáférést, 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. (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örkötéseket kell létrehoznia:

  • A szerepkörök olyan engedélyek készletei, amelyek egy névtéren belül érvényesek. Az engedélyek az erőforrásokon (podokon, üzemelő példányokon stb.) lévő műveletekké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.

  • Létezik egy ClusterRole objektum is, amely egy szerepkörhöz hasonló, 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 ClusterRoleBinding elemet.

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

A konfigurálást követően a Kubernetes API-hoz (például a kubectlen keresztül) hozzáférni kívánó felhasználónak be kell jelentkeznie Azure AD hitelesítő adataival.

Alapértelmezés szerint egy Azure AD 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 RoleBinding-eket hoz létre, amelyek Azure AD 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örkötéseket a fürt rendszergazdája? Az AKS-fürtök valójában kétféle hitelesítő adattal hívják meg a Kubernetes API-kiszolgálót: a fürtfelhasználót és a fürt rendszergazdáját. 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örkötések létrehozásához.

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:

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

• A "Azure Kubernetes Service fürtfelhasználói szerepkör" engedéllyel rendelkezik a fürt felhasználói hitelesítő adatainak letöltéséhez. Nem rendszergazdai felhasználók is hozzárendelhetők ehhez a szerepkörhöz. Ez a szerepkör nem ad konkrét engedélyeket a fürtön belüli Kubernetes-erőforrásokhoz – csak lehetővé teszi a felhasználó számára az API-kiszolgálóhoz való csatlakozást.

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

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

Ajánlott a Kubernetes RBAC-engedélyek hatókörét névtér alapján, szerepkörök és RoleBindingek használatával hatókörbe helyezni a ClusterRoles és a ClusterRoleBindings helyett.

Végül felmerül a kérdés, hogy az AKS-fürtnek milyen engedélyekkel kell azure-erőforrásokat létrehoznia és kezelnie, például terheléselosztókat, hálózatkezelést vagy tárolást. Az Azure API-kkal való hitelesítéshez a fürt egy Azure AD 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 a minimális RBAC-engedélyeket. További információ: Szolgáltatásnevek Azure Kubernetes Service.

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

Az alkalmazásoknak és szolgáltatásoknak gyakran olyan hitelesítő adatokra van szükségük, amelyek lehetővé teszik számukra az olyan külső szolgáltatásokhoz való csatlakozást, mint az Azure Storage vagy a SQL Database. 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 egy Azure AD-ben 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 hozzá egy szolgáltatásnévvel Azure AD, és OAuth 2.0-jogkivonatokkal hitelesíti magát. A végrehajtási folyamat meghív egy localhost-címet a jogkivonat lekéréséhez. Így nem kell jelszavakat vagy kapcsolati sztringeket tárolnia. A felügyelt identitásokat az AKS-ben úgy használhatja, hogy identitásokat rendel az egyes podokhoz az aad-pod-identity projekt 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 Azure AD 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 néhány hitelesítő adatot vagy más alkalmazáskulcsot kell tárolnia, függetlenül attól, hogy a felügyelt identitásokat nem támogató Azure-szolgáltatások, külső szolgáltatások, API-kulcsok stb. Íme néhány lehetőség a titkos kódok biztonságos tárolására:

• Azure Key Vault. Az AKS-ben kötetként csatlakoztathat egy vagy több titkos kódot Key Vault. A kötet beolvassa a titkos kódokat Key Vault. A pod ezután ugyanúgy olvashatja a titkos kódokat, mint egy normál kötetet. További információ: secrets-store-csi-driver-provider-azure project on GitHub.

  A pod egy podidentitás (fent leírt) vagy egy Azure AD szolgáltatásnév és egy titkos ügyfélkód használatával hitelesíti magát. A podidentitások használata ajánlott, mert ebben az esetben nincs szükség az ügyfélkódra.

• HashiCorp Vault. A Kubernetes-alkalmazások Azure AD felügyelt identitások használatával végezhetnek hitelesítést a HashiCorp Vaulttal. Lásd: HashiCorp Vault beszél Azure Active Directory. A Tárolót üzembe helyezheti a Kubernetesben, és érdemes lehet külön dedikált fürtön futtatni az alkalmazásfürttől.

• 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 néhány kihívással is szembe kell néznie. 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 titkosítási kulcsokat a Microsoft kezeli.

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özponti ellenőrzése.
• Annak biztosítása, hogy az összes titkos kód titkosítva legyen inaktív állapotban.
• Központosított kulcskezelés.
• Titkos kódok hozzáférés-vezérlése.
• Naplózás

Tároló- és Orchestrator-biztonság

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

• Fenyegetésfigyelés: 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 külső felektől származó képességeket. Emellett integrálhatja a naplókat az Azure Monitor tárolómonitorozási megoldásából a Microsoft Sentinelbe vagy egy meglévő SIEM-megoldásba.

• Biztonsági rések monitorozása: Folyamatosan monitorozza a rendszerképeket és futtatja a tárolókat az ismert biztonsági résekért Felhőhöz készült Microsoft Defender vagy a Azure Marketplace keresztül elérhető külső megoldással.

• A képjavítás automatizálása a 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-lemezképek és az alkalmazás-keretrendszer rendszerké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 kezelik. Ha ezeket a képeket a felsőbb rétegben javítják, fontos frissíteni, tesztelni és újra üzembe helyezni a saját lemezképeit, hogy ne hagyjon ismert biztonsági réseket. Az ACR Tasks segíthet a folyamat automatizálásában.

• A rendszerképek tárolása megbízható privát beállításjegyzékben, például Azure Container Registry vagy Docker Trusted Registryben. A Kubernetesben érvényesített beléptető webhook használatával biztosíthatja, hogy a podok csak a megbízható beállításjegyzékből tudjanak lekérni képeket.

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

  • Ne futtasson tárolókat emelt szintű 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.

A DevOps megfontolandó szempontjai

Ez a referenciaarchitektúra [Azure Resource Manager-sablon][arm-sablon] segítségével építi ki a felhőbeli erőforrásokat és azok függőségeit. Az [Azure Resource Manager-sablonok][arm-sablon] használatával az [Azure DevOps Services][az-devops] 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 kritériumainak követését az ARM-sablon strukturálásához, a számítási feladatokat általában a funkciók tetszőleges egységeként definiálják; használhat például egy külön sablont a fürthöz, majd más sablont a függő szolgáltatásokhoz. A számítási feladatok elkülönítése lehetővé teszi, hogy a DevOps folyamatos integrációt és folyamatos teljesítést (CI/CD) végezzen, mivel minden számítási feladatot a megfelelő DevOps-csapata társít és kezel.

Üzembe helyezéssel (CI/CD) kapcsolatos szempontok

A mikroszolgáltatás-architektúra robusztus CI/CD-folyamatának néhány célja:

• Minden csapat önállóan hozhatja létre és helyezheti üzembe a tulajdonában lévő szolgáltatásokat anélkül, hogy más csapatokat befolyásolná vagy megzavarná.
• Mielőtt üzembe helyeznénk egy szolgáltatás új verzióját az éles környezetben, a rendszer üzembe helyezi 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 fázisban betartatjuk.
• 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.

További információ a kihívásokról: CI/CD mikroszolgáltatási architektúrákhoz.

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

Költségekkel kapcsolatos szempontok

Az Azure díjkalkulátorával megbecsülheti költségeit. Az egyéb szempontokat a Microsoft Azure Well-Architected-keretrendszer Költség szakasza ismerteti.

Íme néhány megfontolandó szempont az architektúrában használt szolgáltatások közül.

Azure Kubernetes Service (AKS)

A Kubernetes-fürt üzembe helyezése, felügyelete és üzemeltetése nem jár költségekkel az AKS-sel kapcsolatban. Csak a Kubernetes-fürt által felhasznált virtuálisgép-példányokért, tárolókért és a hálózati erőforrásokért kell fizetnie.

A szükséges erőforrások költségeinek becsléséhez tekintse meg a Container Services kalkulátorát.

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. Nincs óránkénti díj a standard Load Balancer, ha nincsenek szabályok konfigurálva.

További információért tekintse meg 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 perc ci/CD-vel és 1 saját üzemeltetésű feladattal, havonta korlátlan percekért ingyenesen futtatható a Microsoft által üzemeltetett feladat, a további feladatok díjfizetéssel járnak. További információkért lásd az Azure DevOps Services díjszabását.

Azure Monitor

Az Azure Monitor Log Analytics esetében az adatbetö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 megoldás üzembe helyezése

Az architektúra referenciaimplementációjának üzembe helyezéséhez kövesse az GitHub adattárban található lépéseket.

Következő lépések

• Ha egy fejlettebb mikroszolgáltatás-példán szeretne dolgozni, tekintse meg a Speciális Azure Kubernetes Service (AKS) mikroszolgáltatás-architektúrát
• Az architektúra monitorozásáról további információt a mikroszolgáltatási architektúra monitorozása az Azure Kubernetes Service -ban (AKS) című témakörben talál.
• Az alkalmazás teljesítményének mérésével kapcsolatos további információkért tekintse meg a teljesítmény finomhangolási forgatókönyvét: Elosztott üzleti tranzakciók.