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 alaparchitektúrájára épül, amely a Microsoft ajánlott kiindulópontja az Azure Kubernetes Service (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.
Architektúra
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:
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.
A betöltési webalkalmazás létrehoz egy üzenetet, és elküldi azt a Service Bus üzenetsorába.
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.
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.
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.
Ajánlások
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. Az alábbi példában a rendszer a hálózati házirendet alkalmazza a háttérrendszer-fejlesztői névtérben lévő podokra egyező app.kubernetes.io/component: backend
címkével. A szabályzat nem tagadja meg a forgalmat, kivéve, ha egy podról származik egy egyezést jelző app.kubernetes.io/part-of: dronedelivery
címkével.
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:
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ő Application Insights APM-monitorozást biztosít a .NET Core-ban, Node.js, Java-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, az Application Insights for Kubernetes-kódtár képekkel, tárolókkal, csomópontokkal, podokkal, címkével és replikakészletekkel bővíti az Application Insights telemetriáját.
Az alábbi ábrán egy példa látható az Application Insights á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.
Következő 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