Advanced Azure Kubernetes Service (AKS) mikroszolgáltatás-architektúra

Ez a referenciaarchitektúra számos konfigurációt ismertet, amelyeket figyelembe kell venni a mikroszolgáltatások Azure Kubernetes Servicesben való futtatásakor. A témakörök közé tartozik a hálózati szabályzatok konfigurálása, a pod automatikus skálázása és az elosztott nyomkövetés egy mikroszolgáltatás-alapú alkalmazáson keresztül.

Ez az architektúra az AKS Alapkonfigurációs architektúrára épül, amely a Microsoft ajánlott kiindulópontja az AKS-infrastruktúrához. Az AKS alapkonfigurációja olyan infrastrukturális funkciókat részletez, mint a Microsoft Entra Számítási feladat ID, a bejövő és kimenő forgalom korlátozásai, az erőforráskorlátok és más biztonságos AKS-infrastruktúra-konfigurációk. Ezek az infrastrukturális részletek nem szerepelnek ebben a dokumentumban. Javasoljuk, hogy a mikroszolgáltatások tartalmának megismerése előtt ismerkedjen meg az AKS alapkonfigurációjával.

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

Felépítés

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

Ha inkább egy alapszintű mikroszolgáltatás-példával szeretne kezdeni az AKS-ben, tekintse meg az AKS Mikroszolgáltatás-architektúrája című témakört.

Munkafolyamat

Ez a kérelemfolyamat implementálja a Publisher-Előfizető, a Versengő felhasználók és az Átjáró-útválasztás felhőtervezési mintáit. Az üzenetkezelési folyamat a következőképpen halad:

1. A drónfelvétel ütemezéséhez HTTPS-kérést küldünk. A kérelmek Azure-alkalmazás Átjárón keresztül jutnak el a betöltési webalkalmazásba, amely az AKS-ben fürtön belüli mikroszolgáltatásként fut.

2. A betöltési webalkalmazás létrehoz egy üzenetet, és elküldi azt a Service Bus üzenetsorába.

3. A háttérrendszer hozzárendel egy drónt, és értesíti a felhasználót. A munkafolyamat:

   • 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árolójának.
   • HTTPS-kérést küld a Drone Scheduler mikroszolgáltatásnak.
   • HTTPS-kérést küld a Csomag mikroszolgáltatásnak, amely adatokat továbbít a MongoDB külső adattárolójának.

4. A RENDSZER HTTPS GET kérést használ a kézbesítési állapot visszaadásához. Ez a kérés áthalad az Application Gatewayen a Kézbesítési mikroszolgáltatásba.

5. A kézbesítési mikroszolgáltatás adatokat olvas be az Azure Cache for Redisből.

Összetevők

Ez az architektúra a következő Azure-összetevőket használja:

Az Azure Kubernetes Service egy Azure-ajánlat, amely felügyelt Kubernetes-fürtöt biztosít. Az AKS használatakor a Kubernetes API-kiszolgálót az Azure felügyeli. A Kubernetes-csomópontok vagy csomópontkészletek elérhetők, és a fürt operátora felügyelheti.

Az architektúrában használt AKS-infrastruktúra-funkciók a következők:

• Rendszer- és felhasználói csomópontkészlet elkülönítése
• AKS által felügyelt Microsoft Entra-azonosító szerepköralapú hozzáférés-vezérléshez (RBAC)
• Microsoft Entra Számítási feladat ID
• Azure Policy-bővítmény az AKS-hez
• Azure Container Networking Interface (CNI)
• Azure Monitor tárolóelemzések

Az Azure-beli virtuális hálózatok elszigetelt és rendkívül biztonságos környezetek virtuális gépek (virtuális gépek) és alkalmazások futtatásához. Ez a referenciaarchitektúra egy társviszonyban lévő küllős virtuális hálózati topológiát használ. A központi virtuális hálózat tartalmazza az Azure-tűzfalat és az Azure Bastion-alhálózatokat. A küllős virtuális hálózat tartalmazza az AKS-rendszert és a felhasználói csomópontkészlet alhálózatait, valamint a Azure-alkalmazás Átjáró alhálózatot.

Az Azure Private Link meghatározott privát IP-címeket rendel hozzá az Azure Container Registryhez és a Key Vaulthoz az AKS rendszer és a felhasználói csomópontkészlet alhálózatán belüli privát végpontokról .

Azure-alkalmazás átjáró a webalkalmazási tűzfal (WAF) HTTP-útvonalakat tesz elérhetővé az AKS-fürthöz, a terhelés pedig kiegyensúlyozza a webalkalmazás felé irányuló webes forgalmat. Ez az architektúra Azure-alkalmazás Átjáró bejövőforgalom-vezérlőt (AGIC) használ a Kubernetes bejövőforgalom-vezérlőjeként.

Az Azure Bastion biztonságos távoli asztali protokollt (RDP) és biztonságos rendszerhéjat (SSH) biztosít a virtuális hálózatok virtuális gépeihez egy biztonságos szoftvercsatornás réteg (SSL) használatával, anélkül, hogy nyilvános IP-címeken kellene elérhetővé tenni a virtuális gépeket.

Az Azure Firewall egy hálózati biztonsági szolgáltatás, amely minden Azure-beli virtuális hálózati erőforrást véd. A tűzfal csak jóváhagyott szolgáltatásokat és teljes tartományneveket (FQDN-eket) engedélyez kimenő forgalomként.

Külső tároló és egyéb összetevők:

Az Azure Key Vault tárolja és kezeli az AKS-szolgáltatások biztonsági kulcsait.

Az Azure Container Registry privát tárolórendszerképeket tárol, amelyek az AKS-fürtben futtathatók. Az AKS a Tárolóregisztrációs adatbázissal hitelesíti a Microsoft Entra által felügyelt identitását. Más tárolóregisztrációs adatbázisokat is használhat, például a Docker Hubot.

Az Azure Cosmos DB a Nyílt forráskódú Azure Cosmos DB for MongoDB használatával tárolja az adatokat. A mikroszolgáltatások általában állapot nélküliek, és az állapotukat külső adattárakba írják. Az Azure Cosmos DB egy Olyan NoSQL-adatbázis, amely nyílt forráskódú API-kat biztosít a MongoDB-hez és a Cassandra-hoz.

Az Azure Service Bus szolgáltatásként megbízható felhőbeli üzenetkezelést és egyszerű hibrid integrációt kínál. A Service Bus támogatja a mikroszolgáltatás-alkalmazásokban gyakran használt aszinkron üzenetkezelési mintákat.

Az Azure Cache for Redis egy gyorsítótárazási réteget ad hozzá az alkalmazásarchitektúrához a nagy terhelések sebességének és teljesítményének javítása érdekében.

Az Azure Monitor metrikákat és naplókat gyűjt és tárol, beleértve az alkalmazás telemetriáját, valamint az Azure platform- és szolgáltatásmetrikáit. Ezekkel az adatokkal monitorozhatja az alkalmazást, riasztásokat és irányítópultokat állíthat be, és elvégezheti a hibák kiváltó okainak elemzését.

Egyéb operációsrendszer-támogató rendszerösszetevők:

Helm, a Kubernetes csomagkezelője, amely a Kubernetes-objektumokat egyetlen egységbe csomagolja, amelyet közzétehet, üzembe helyezhet, verziószámozhat és frissíthet.

Az Azure Key Vault titkos tár CSI-szolgáltatója lekéri az Azure Key Vaultban tárolt titkos kulcsokat, és a Titkos tár CSI illesztőfelületével csatlakoztatja őket a Kubernetes-podokhoz.

Flux, egy nyílt és bővíthető folyamatos kézbesítési megoldás a Kubernetes számára, a GitOps Toolkit segítségével.

Forgatókönyv részletei

Az előző ábrán látható Fabrikam Drone Delivery Shipping App példa a cikkben tárgyalt architekturális összetevőket és eljárásokat valósítja meg. Ebben a példában a Fabrikam, Inc., egy 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 kérhetik egy termék drónos kézbesítését. 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 kézbesítési időről. Amíg a kézbesítés folyamatban van, az ügyfél egy folyamatosan frissített ETA-val nyomon követheti a drón helyét.

Lehetséges használati esetek

Ez a megoldás ideális a repülőgép-, a repülőgép- és a repülőipar számára.

Javaslatok

Ezeket a javaslatokat a speciális AKS-mikroszolgáltatás-architektúrák üzembe helyezésekor implementálhatja.

Application Gateway bejövőforgalom-vezérlő (AGIC)

Az API Gateway Routing egy általános mikroszolgáltatás-tervezési minta. Az API-átjáró fordított proxyként működik, amely átirányítja az ügyfelektől érkező kéréseket a mikroszolgáltatásokhoz. A Kubernetes bejövő erőforrása és a bejövőforgalom-vezérlő a következőkkel kezeli a legtöbb API Gateway-funkciót:

Az ügyfélkérések megfelelő háttérszolgáltatásokhoz való átirányítása egyetlen végpontot biztosít az ügyfelek számára, és segítséget nyújt az ügyfelek szolgáltatásoktól való leválasztásához.

• 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.
• Az olyan funkciók kiszervezése, mint az SSL leállítása, a hitelesítés, az IP-korlátozások és az ügyfélsebesség-korlátozás vagy a háttérszolgáltatásokról való szabályozás.

Az AKS-fürt állapota az Application Gateway-specifikus konfigurációra lesz lefordítva, és az Azure Resource Manageren keresztül lesz alkalmazva.

A külső bejövőforgalom-vezérlők leegyszerűsítik az AKS-fürtökbe történő adatbetöltést, javítják a biztonságot és a teljesítményt, és erőforrásokat takarítanak meg. Ez az architektúra a Azure-alkalmazás Átjáró bejövőforgalom-vezérlőt (AGIC) használja a bejövő forgalom vezérléséhez. Az Application Gateway használata az összes forgalom kezeléséhez szükségtelenné teszi a további terheléselosztó használatát. Mivel a podok közvetlen kapcsolatokat létesítenek az Application Gatewayhez, a szükséges ugrások száma csökken, ami jobb teljesítményt eredményez.

Az Application Gateway beépített automatikus skálázási képességekkel rendelkezik, ellentétben a fürtön belüli bejövőforgalom-vezérlőkkel, amelyeket fel kell méretezni, ha nem kívánt mennyiségű számítási erőforrást használnak fel. Az Application Gateway képes a 7. rétegbeli útválasztásra és AZ SSL-leállításra, és beépített webalkalmazási tűzfallal (WAF) integrálva van a teljes körű transport Layer Security (TLS) szolgáltatással.

Az AGIC bejövő forgalmának beállításához engedélyeznie kell a CNI-hálózatkezelést az AKS-fürt konfigurálásakor, mivel az Application Gateway az AKS virtuális hálózat alhálózatán van üzembe helyezve. A több-bérlős számítási feladatokhoz vagy a fejlesztési és tesztelési környezeteket támogató egyetlen fürthöz több bejövő vezérlőre lehet szükség.

Nulla megbízhatóságú hálózati szabályzatok

A hálózati házirendek meghatározzák, hogy az AKS-podok hogyan kommunikálhatnak egymással és más hálózati végpontokkal. Alapértelmezés szerint az összes bejövő és kimenő forgalom engedélyezve van a podokra és a podokról. Amikor megtervezi, hogyan kommunikálnak a mikroszolgáltatások egymással és más végpontokkal, fontolja meg a zéró megbízhatósági elv követését, ahol bármely szolgáltatáshoz, eszközhöz, alkalmazáshoz vagy adatadattárhoz való hozzáférés explicit konfigurációt igényel.

A nulla megbízhatósági szabályzat megvalósításának egyik stratégiája egy olyan hálózati szabályzat létrehozása, amely a célnévtérben lévő összes pod bejövő és kimenő forgalmát tagadja meg. Az alábbi példában egy "minden szabályzat megtagadása" látható, amely a háttérrendszer-dev névtérben található összes podra vonatkozik.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

A korlátozó szabályzat életbe lépése után meg kell határoznia azokat a hálózati szabályokat, amelyek lehetővé teszik a mikroszolgáltatás egyes podjainak bejövő és kimenő forgalmát. A következő példában a rendszer a hálózati házirendet alkalmazza a háttérrendszer-fejlesztői névtérben lévő podokra, és egy olyan címkével rendelkezik, amely megfelel app.kubernetes.io/component: háttérrendszernek. A szabályzat nem tagadja meg a forgalmat, kivéve, ha olyan podról származik, amely egy app.kubernetes.io/part-of: dronedelivery címkével rendelkezik.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

A Kubernetes hálózati házirendjeiről és a lehetséges alapértelmezett szabályzatokra vonatkozó további példákért tekintse meg a Kubernetes dokumentációjában található hálózati házirendeket.

Erőforráskvóták

Az erőforráskvótákkal a rendszergazdák lefoglalhatják és korlátozhatják az erőforrásokat egy fejlesztői csapat vagy projekt számára. Erőforráskvótákat beállíthat egy névtéren, és azokkal korlátozhatja a következő értékeket:

• Számítási erőforrások, például processzor és memória vagy GPU-k.
• Tárolási erőforrások, beleértve egy adott tárolási osztály köteteinek számát vagy lemezterületét.
• Az objektumok száma, például a létrehozható titkos kódok, szolgáltatások vagy feladatok maximális száma.

Ha az erőforrás-kérelmek vagy korlátok összesített összege megfelel a hozzárendelt kvótának, nem lesznek sikeresek a további üzembe helyezések.

Az erőforráskvóták biztosítják, hogy a névtérhez rendelt podok teljes készlete ne lépje túl a névtér erőforráskvótáit. Az előtér nem tudja éhezni az erőforrások háttérszolgáltatását, vagy fordítva.

Erőforráskvóták meghatározásakor a névtérben létrehozott összes podnak korlátozásokat vagy kéréseket kell megadnia a pod specifikációiban. Ha nem adják meg ezeket az értékeket, a rendszer elutasítja az üzembe helyezést.

Az alábbi példa egy pod-specifikációt mutat be, amely erőforráskvóta-kérelmeket és korlátokat állít be:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

További információ az erőforráskvótákról:

• Erőforráskvóták kényszerítése
• Erőforráskvóták

Automatikus skálázás

A Kubernetes támogatja az automatikus skálázást az üzembe helyezéshez lefoglalt podok számának növeléséhez, vagy a fürt csomópontjainak növeléséhez a teljes rendelkezésre álló számítási erőforrás növeléséhez. Az automatikus skálázás önkorrekt autonóm visszajelzési rendszer. Bár manuálisan skálázhatja a podokat és a csomópontokat, az automatikus skálázás minimalizálja annak az esélyét, hogy a szolgáltatások erőforrás-éhezésbe kerüljenek nagy terhelés esetén. Az automatikus skálázási stratégiának figyelembe kell vennie a podokat és a csomópontokat is.

Fürt automatikus skálázása

A fürt automatikus skálázási ( CA) skálázza a csomópontok számát. Tegyük fel, hogy a podok erőforrás-korlátozások miatt nem ütemezhetők; a fürt automatikus skálázója további csomópontokat helyez üzembe. Meg kell határoznia a csomópontok minimális számát az AKS-fürt és a számítási feladatok működésének fenntartásához, valamint a nagy forgalomhoz szükséges csomópontok maximális számát. A hitelesítésszolgáltató néhány másodpercenként ellenőrzi a függőben lévő podokat vagy üres csomópontokat, és megfelelően skálázza az AKS-fürtöt.

Az alábbi példa az ARM-sablon ca-konfigurációját mutatja be:

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

Az ARM-sablon alábbi sorai a hitelesítésszolgáltatóhoz tartozó minimális és maximális csomópontokat állítják be:

"minCount": 2,
"maxCount": 5,

Pod automatikus skálázása

A vízszintes podok automatikus skálázása (HPA) a podokat a megfigyelt CPU-, memória- vagy egyéni metrikák alapján skálázza. A horizontális podméretezés konfigurálásához meg kell adnia a célmetrikákat, valamint a Kubernetes üzembehelyezési pod specifikációjában a replikák minimális és maximális számát. Töltse be a szolgáltatások tesztelését ezeknek a számoknak a meghatározásához.

A CA és a HPA jól együttműködik, ezért engedélyezze mindkét automatikus skálázási lehetőséget az AKS-fürtben. A HPA skálázza az alkalmazást, míg a hitelesítésszolgáltató skálázza az infrastruktúrát.

Az alábbi példa a HPA erőforrásmetrikáit állítja be:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

A HPA a ténylegesen felhasznált erőforrásokat vagy a futó podokból származó egyéb metrikákat vizsgálja, de a hitelesítésszolgáltató a még nem ütemezett podok csomópontjait helyezi üzembe. A hitelesítésszolgáltató ezért a pod specifikációjában megadott módon megvizsgálja a kért erőforrásokat. Az értékek finomhangolásához használjon terheléstesztelést.

Állapotminták

A Kubernetes load balances traffic to pods, amely megfelel a szolgáltatás címkeválasztójának. Csak a sikeresen elindult és kifogástalan állapotú podok fogadják a forgalmat. Ha egy tároló összeomlik, a Kubernetes eltávolítja a podot, és ütemez egy cserét.

A Kubernetesben a podok kétféle állapotmintát tehetnek közzé:

• Az élőség-mintavétel jelzi a Kubernetesnek, hogy egy pod sikeresen elindult-e, és kifogástalan állapotban van-e.
• A készültségi mintavétel jelzi a Kubernetesnek, hogy egy pod készen áll-e a kérések elfogadására.

Az élőségi mintavételek kezelik azokat a podokat, amelyek még futnak, de nem kifogástalanok, és újra kell hasznosítani. Ha például lefagy egy HTTP-kéréseket kiszolgáló tároló, a tároló nem összeomlik, de leállítja a kérések kiszolgálását. A HTTP-élőség-mintavétel nem válaszol, ami tájékoztatja a Kubernetes-t a pod újraindításáról.

Előfordulhat, hogy egy pod nem áll készen a forgalom fogadására, annak ellenére, hogy a pod sikeresen elindult. Előfordulhat például, hogy a tárolóban futó alkalmazás inicializálási feladatokat hajt végre. A készültségi mintavétel azt jelzi, hogy a pod készen áll-e a forgalom fogadására.

A mikroszolgáltatásoknak olyan végpontokat kell elérhetővé tenniük a kódjukban, amelyek megkönnyítik az állapotteszteket, és a késést és az időtúllépést kifejezetten az általuk végzett ellenőrzésekre szabják. A HPA-képlet szinte kizárólag a pod Kész fázisában található, ezért kritikus fontosságú, hogy az állapotminták léteznek és pontosak legyenek.

Figyelés

A mikroszolgáltatás-alkalmazásokban az Alkalmazásteljesítmény-kezelés (APM) monitorozása kritikus fontosságú az anomáliák észleléséhez, a problémák diagnosztizáléséhez és a szolgáltatások közötti függőségek gyors megértéséhez. Az Azure Monitor részét képező alkalmazás Elemzések APM-monitorozást biztosít a .NET Core-ban, Node.js-ben, Javában és sok más alkalmazásnyelven írt élő alkalmazásokhoz.

Application Insights:

• HTTP-kéréseket naplóz, beleértve a késést és az eredménykódot.
• Alapértelmezés szerint engedélyezi az elosztott nyomkövetést.
• Tartalmaz egy műveletazonosítót a nyomkövetésekben, így egy adott művelethez tartozó összes nyomkövetés megfeleltethető.
• Gyakran további környezeti információkat is tartalmaz a nyomkövetésekben.

A szolgáltatások telemetriájának a Kubernetes-világgal való kontextusba helyezéséhez integrálja az Azure Monitor telemetriát az AKS-sel, hogy metrikákat gyűjtsön a vezérlőkből, csomópontokból és tárolókból, valamint tároló- és csomópontnaplókból. Ha .NET-et használ, a Kubernetes-kódtárhoz készült Alkalmazás Elemzések az Alkalmazás Elemzések telemetriát kép-, tároló-, csomópont-, pod-, címke- és replikakészlet-információkkal bővíti.

Az alábbi ábrán egy példa látható az Alkalmazás Elemzések által az AKS mikroszolgáltatások telemetriai nyomkövetéséhez létrehozott alkalmazásfüggőségi térképre:

Az Application Insights-integrációhoz használt közös nyelvek rendszerezésének lehetőségeiről további információt a Kubernetes alkalmazásmonitorozása című témakörben talál.

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 halmaza. További információ: Microsoft Azure Well-Architected Framework.

Méretezhetőség

A méretezhetőség tervezésekor vegye figyelembe az alábbi szempontokat.

• Ne kombinálja az automatikus skálázást, valamint a replikák számának imperatív vagy deklaratív kezelését. A felhasználók és az automatikus skálázók is megkísérlik módosítani a replikák számát, váratlan viselkedést okozhatnak. Ha a HPA engedélyezve van, csökkentse a replikák számát az üzembe helyezni kívánt minimális számra.

• A podok automatikus skálázásának egyik mellékhatása, hogy a podok gyakran hozhatók létre vagy kiüríthetők a horizontális felskálázás és a horizontális felskálázás során. A hatások mérséklése:

  • Készenlét-mintavételekkel tudathatja a Kubernetes-sel, hogy egy új pod készen áll-e a forgalom elfogadására.
  • Podkimaradási költségvetések használatával korlátozhatja, hogy egyszerre hány podot lehet kiüríteni egy szolgáltatásból.

• A fürt létrehozása után nem módosíthatja a virtuális gép méretét, ezért a kezdeti kapacitástervezés során a fürt létrehozásakor válassza ki az ügynökcsomópontoknak megfelelő virtuálisgép-méretet.

• A több-bérlős vagy más speciális számítási feladatok csomópontkészlet-elkülönítési követelményekkel rendelkezhetnek, amelyek több és valószínűleg kisebb alhálózatot igényelnek. További információ az egyedi alhálózatokkal rendelkező csomópontkészletek létrehozásáról: Csomópontkészlet hozzáadása egyedi alhálózattal. A szervezetek eltérő szabványokkal rendelkeznek a küllős megvalósításukhoz. Ügyeljen arra, hogy kövesse a szervezeti irányelveket.

Kezelhetőség

A kezelhetőség tervezésekor vegye figyelembe az alábbi szempontokat.

• Az AKS-fürtinfrastruktúra kezelése automatizált üzembe helyezési folyamaton keresztül. Az architektúra referencia-implementációja egy GitHub Actions-munkafolyamatot biztosít, amely a folyamat létrehozásakor használható.

• A munkafolyamat-fájl csak az infrastruktúrát helyezi üzembe, nem pedig a számítási feladatot a már meglévő virtuális hálózatba és a Microsoft Entra-konfigurációba. Az infrastruktúra és a számítási feladatok külön üzembe helyezése lehetővé teszi a különböző életciklus- és üzemeltetési problémák kezelését.

• Ha regionális hiba történik, vegye figyelembe a munkafolyamatot egy másik régióban történő üzembe helyezés mechanizmusaként. Hozza létre a folyamatot, hogy paraméter- és bemeneti módosításokkal üzembe helyezhesse az új fürtöt egy új régió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ó: A biztonsági pillér áttekintése.

A biztonság tervezésekor vegye figyelembe a következő szempontokat.

• Az AKS-pod a Microsoft Entra ID-ben tárolt számítási feladatok identitásával hitelesíti magát. A számítási feladatok identitásának használata előnyösebb, mert nem igényel ügyfélkulcsot.

• Felügyelt identitásokkal a végrehajtási folyamat gyorsan lekérheti az Azure Resource Manager OAuth 2.0-jogkivonatokat; nincs szükség jelszavakra vagy kapcsolati sztring. Az AKS-ben identitásokat rendelhet az egyes podokhoz Microsoft Entra Számítási feladat ID használatával.

• A mikroszolgáltatási alkalmazás minden szolgáltatásához egyedi számítási feladat-identitást kell hozzárendelni, hogy megkönnyítse a legkevésbé kiemelt RBAC-hozzárendeléseket. Csak olyan szolgáltatásokhoz rendeljen identitásokat, amelyekhez szükség van rájuk.

• Azokban az esetekben, amikor egy alkalmazásösszetevőhöz Kubernetes API-hozzáférés szükséges, győződjön meg arról, hogy az alkalmazás podjai úgy vannak konfigurálva, hogy megfelelő hatókörű API-hozzáféréssel rendelkező szolgáltatásfiókot használjanak. A Kubernetes-szolgáltatásfiók konfigurálásával és kezelésével kapcsolatos további információkért lásd: Kubernetes-szolgáltatásfiókok kezelése.

• Nem minden Azure-szolgáltatás támogatja az adatsíkok Microsoft Entra-azonosítóval történő hitelesítését. A hitelesítő adatok vagy az alkalmazás titkos kulcsainak tárolásához használja az Azure Key Vaultot az adott szolgáltatásokhoz, külső szolgáltatásokhoz vagy API-kulcsokhoz. Az Azure Key Vault központosított felügyeletet, hozzáférés-vezérlést, inaktív titkosítást és az összes kulcs és titkos kulcs naplózását biztosítja.

• Az AKS-ben kötetként csatlakoztathat egy vagy több titkos kulcsot a Key Vaultból. A pod ezután ugyanúgy beolvassa a Key Vault titkos kulcsokat, mint egy normál kötetet. További információ: secrets-store-csi-driver-provider-azure projekt a GitHubon.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információ: A költségoptimalizálási pillér áttekintése.

• A Microsoft Azure Well-Architected Framework Költség szakasza a költség szempontjait ismerteti. Az Azure díjkalkulátorával megbecsülheti az adott forgatókönyv költségeit.

• Az AKS-nek nincsenek költségei a Kubernetes-fürt üzembe helyezésével, felügyeletével és üzemeltetésével kapcsolatban. Csak a fürt által felhasznált virtuálisgép-példányokért, tárolási és hálózati erőforrásokért kell fizetnie. A fürt automatikus skálázása jelentősen csökkentheti a fürt költségeit üres vagy nem használt csomópontok eltávolításával.

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

• Fontolja meg az AKS költségelemzésének engedélyezését a fürtinfrastruktúra részletes költségfelosztásához a Kubernetes-specifikus szerkezetek szerint.

További lépések

• Az Azure Kubernetes Service bemutatása
• Mi az Az Azure Virtual Networks?
• Mi az az Azure privát kapcsolat?
• Mi az Azure-alkalmazás Átjáró?
• Mi az az Azure Bastion?
• Az Azure Key Vault bemutatása
• Az Azure Container Registry bemutatása
• Bevezetés az Azure Cosmos DB-e
• Azure Monitor – áttekintés

Kapcsolódó erőforrások

• Azure Kubernetes Service-fürt alaparchitektúrája
• Mikroszolgáltatások tervezése, létrehozása és üzemeltetése az Azure-ban a Kubernetes használatával
• Mikroszolgáltatás-architektúra az AKS-en
• Mikroszolgáltatás-architektúra monitorozása az AKS-ben
• Teljesítmény-finomhangolási forgatókönyv: Elosztott üzleti tranzakciók
• CI/CD-folyamat létrehozása mikroszolgáltatásokhoz a Kubernetesen