Az Azure API Management használata az Azure Kubernetes Service-ben üzembe helyezett mikroszolgáltatásokkal

A KÖVETKEZŐRE VONATKOZIK: Minden API Management-szint

A mikroszolgáltatások tökéletesek API-k készítéséhez. Az Azure Kubernetes Service (AKS) segítségével gyorsan üzembe helyezhet és üzemeltethet mikroszolgáltatás-alapú architektúrát a felhőben. Ezután az Azure API Management (API Management) használatával közzéteheti mikroszolgáltatásait API-kként belső és külső felhasználás céljából. Ez a cikk az API Management AKS-sel való üzembe helyezésének lehetőségeit ismerteti. Feltételezi a Kubernetes, az API Management és az Azure hálózatkezelés alapszintű ismereteit.

Háttér

Ha a mikroszolgáltatásokat API-kként teszi közzé fogyasztásra, nehéz lehet kezelni a mikroszolgáltatások és az azokat használó ügyfelek közötti kommunikációt. Számos horizontális szempont létezik, például hitelesítés, engedélyezés, szabályozás, gyorsítótárazás, átalakítás és monitorozás. Ezek az aggodalmak attól függetlenül érvényesek, hogy a mikroszolgáltatások belső vagy külső ügyfeleknek vannak-e kitéve.

Az API Gateway-minta ezeket a problémákat kezeli. Az API-átjárók a mikroszolgáltatások első ajtójaként szolgálnak, leválasztják az ügyfeleket a mikroszolgáltatásokról, további biztonsági réteget adnak hozzá, és csökkentik a mikroszolgáltatások összetettségét azáltal, hogy megszüntetik a keresztvágási problémák kezelésének terheit.

Az Azure API Management egy kulcsrakész megoldás az API-átjáró igényeinek kielégítésére. Gyorsan létrehozhat egy konzisztens és modern átjárót a mikroszolgáltatásokhoz, és API-kként közzéteheti őket. Teljes életciklusú API-felügyeleti megoldásként további képességeket is kínál, például önkiszolgáló fejlesztői portált az API-felderítéshez, az API-életciklus-kezeléshez és az API-elemzéshez.

Együttes használat esetén az AKS és az API Management platformot biztosít a mikroszolgáltatás-alapú API-k üzembe helyezéséhez, közzétételéhez, biztonságossá tételéhez, monitorozásához és felügyeletéhez. Ebben a cikkben bemutatunk néhány lehetőséget az AKS és az API Management együttes üzembe helyezésére.

Kubernetes Services és API-k

A Kubernetes-fürtökben a tárolók podokban vannak üzembe helyezve, amelyek rövid élettartamúak. Amikor egy feldolgozó csomópont meghal, a csomóponton futó podok elvesznek. Ezért a Pod IP-címe bármikor változhat. Nem hagyatkozhatunk rá, hogy kommunikáljunk a podkal.

A probléma megoldásához a Kubernetes bevezette a szolgáltatások fogalmát. A Kubernetes-szolgáltatás egy absztrakciós réteg, amely podok logikai csoportját határozza meg, és lehetővé teszi a külső forgalomnak való kitettséget, a terheléselosztást és a szolgáltatásfelderítést ezen podok számára.

Ha készen állunk a mikroszolgáltatások API-kként való közzétételére az API Managementen keresztül, át kell gondolnunk, hogyan képezhetjük le a Kubernetes-szolgáltatásokat API-kra az API Managementben. Nincsenek beállított szabályok. Ez attól függ, hogyan tervezte és particionálta az üzleti képességeit vagy tartományait mikroszolgáltatásokra az elején. Ha például a szolgáltatás mögötti podok egy adott erőforráson (például ügyfélen) végzett összes műveletért felelősek, a szolgáltatás egy API-ra képezhető le. Ha egy erőforrás műveletei több mikroszolgáltatásra vannak particionálva (például GetOrder, PlaceOrder), akkor több szolgáltatás logikailag egyetlen API-ba összesíthető az API-felügyeletben (lásd az 1. ábrát).

A leképezések is fejlődhetnek. Mivel az API Management egy homlokzatot hoz létre a mikroszolgáltatások előtt, lehetővé teszi a mikroszolgáltatások időről időre történő újrabontását és megfelelő méretezését.

API Management üzembe helyezése az AKS előtt

Az API Management egy AKS-fürt előtt való üzembe helyezésének néhány lehetősége van.

Bár az AKS-fürtök mindig virtuális hálózaton (VNeten) üzemelnek, egy API Management-példányt nem kell üzembe helyezni egy virtuális hálózaton. Ha az API Management nem a fürt virtuális hálózatán belül található, az AKS-fürtnek nyilvános végpontokat kell közzétennie az API Management számára a csatlakozáshoz. Ebben az esetben biztosítani kell az API Management és az AKS közötti kapcsolatot. Más szóval biztosítanunk kell, hogy a fürt csak az API Managementen keresztül érhető el. Tekintsük át a lehetőségeket.

1. lehetőség: Szolgáltatások nyilvános közzététele

Az AKS-fürtök szolgáltatásai nyilvánosan közzétehetők a NodePort, a LoadBalancer vagy a ExternalName szolgáltatástípusokkal. Ebben az esetben a szolgáltatások közvetlenül a nyilvános internetről érhetők el. Miután üzembe helyeztük az API Managementet a fürt előtt, biztosítanunk kell, hogy az összes bejövő forgalom áthaladjon az API Managementen a mikroszolgáltatásokban való hitelesítés alkalmazásával. Az API Management például egy hozzáférési jogkivonatot is tartalmazhat a fürtnek küldött összes kérelemben. Minden mikroszolgáltatás felelős a jogkivonat érvényesítéséért a kérés feldolgozása előtt.

Ez lehet a legegyszerűbb lehetőség az API Management üzembe helyezésére az AKS előtt, különösen akkor, ha már implementált hitelesítési logikát a mikroszolgáltatásokban.

Profik:

• Egyszerű konfiguráció az API Management oldalán, mert nem kell a fürt virtuális hálózatába injektálnia
• Nincs változás az AKS oldalán, ha a szolgáltatások már nyilvánosan elérhetők, és a hitelesítési logika már létezik a mikroszolgáltatásokban

Hátránya:

• Lehetséges biztonsági kockázat a végpontok nyilvános láthatósága miatt
• Nincs egyetlen belépési pont a bejövő fürtforgalomhoz
• Duplikált hitelesítési logikával bonyolítja a mikroszolgáltatásokat

2. lehetőség: Bejövőforgalom-vezérlő telepítése

Bár az 1. lehetőség egyszerűbb lehet, jelentős hátrányai vannak a fent említetteknek. Ha egy API Management-példány nem található a fürt virtuális hálózatában, a kölcsönös TLS-hitelesítés (mTLS) hatékony módja annak, hogy az API Management-példány és az AKS-fürt közötti forgalom mindkét irányban biztonságos és megbízható legyen.

A kölcsönös TLS-hitelesítést az API Management natív módon támogatja, és a Kubernetesben egy bejövőforgalom-vezérlő telepítésével engedélyezhető (3. ábra). Ennek eredményeképpen a rendszer hitelesítést hajt végre a bejövőforgalom-vezérlőben, ami leegyszerűsíti a mikroszolgáltatásokat. Emellett hozzáadhatja az API Management IP-címeit az engedélyezett listához bejövő forgalommal, hogy csak az API Management férhessen hozzá a fürthöz.

Profik:

• Egyszerű konfiguráció az API Management oldalán, mert nem kell a fürt virtuális hálózatába injektálni, és az mTLS natív módon támogatott
• Központosítja a bejövő fürtforgalom védelmét a Bejövőforgalom-vezérlő rétegben
• Csökkenti a biztonsági kockázatot a nyilvánosan látható fürtvégpontok minimalizálásával

Hátránya:

• Növeli a fürtkonfiguráció összetettségét, mivel a bejövőforgalom-vezérlő telepítése, konfigurálása és karbantartása, valamint az mTLS-hez használt tanúsítványok kezelése többletmunkával jár
• Biztonsági kockázat a bejövőforgalom-vezérlő végpont(ok) nyilvános láthatósága miatt

Amikor API-kat tesz közzé az API Management használatával, egyszerű és gyakori, hogy az előfizetési kulcsok használatával biztonságosan hozzáfér ezekhez az API-khoz. A közzétett API-k használatához szükséges fejlesztőknek érvényes előfizetési kulcsot kell tartalmazniuk a HTTP-kérésekben, amikor hívásokat kezdeményeznek az adott API-khoz. Ellenkező esetben az API Management-átjáró azonnal elutasítja a hívásokat. A háttérszolgáltatások nem továbbítják őket.

Az API-k eléréséhez szükséges előfizetési kulcs lekérése. Az előfizetés lényegében egy elnevezett tároló az előfizetési kulcsok párjának. Azok a fejlesztők, akiknek a közzétett API-kat kell használniuk, előfizetéseket szerezhetnek be. És nincs szükségük az API-közzétevők jóváhagyására. Az API-közzétevők közvetlenül is létrehozhatnak előfizetéseket az API-felhasználók számára.

3. lehetőség: APIM üzembe helyezése a fürt virtuális hálózatán belül

Bizonyos esetekben a szabályozási korlátozásokkal vagy szigorú biztonsági követelményekkel rendelkező ügyfelek az 1. és a 2. lehetőséget nem találják életképes megoldásnak a nyilvánosan közzétett végpontok miatt. Más esetekben előfordulhat, hogy az AKS-fürt és a mikroszolgáltatásokat használó alkalmazások ugyanabban a virtuális hálózaton belül találhatók, ezért nincs ok arra, hogy nyilvánosan tegye közzé a fürtöt, mivel minden API-forgalom a virtuális hálózaton belül marad. Ezekben a forgatókönyvekben az API Managementet üzembe helyezheti a fürt virtuális hálózatán. Az API Management Fejlesztői és Prémium szintjei támogatják a virtuális hálózatok üzembe helyezését.

Az API Management virtuális hálózaton való üzembe helyezésének két módja van: külső és belső.

Ha az API-fogyasztók nem a fürt virtuális hálózatában találhatók, a külső módot (4. ábra) kell használni. Ebben a módban az API Management-átjárót a rendszer a fürt virtuális hálózatába injektálja, de egy külső terheléselosztón keresztül elérhető a nyilvános internetről. Segít teljesen elrejteni a fürtöt, miközben a külső ügyfelek továbbra is felhasználhatják a mikroszolgáltatásokat. Emellett azure-beli hálózati képességeket, például hálózati biztonsági csoportokat (NSG) is használhat a hálózati forgalom korlátozásához.

Ha minden API-fogyasztó a fürt virtuális hálózatán belül található, akkor a belső mód (5. ábra) használható. Ebben a módban az API Management-átjárót a rendszer a fürt virtuális hálózatába injektálja, és csak ebből a virtuális hálózatból érhető el egy belső terheléselosztón keresztül. A nyilvános internetről nem lehet elérni az API Management-átjárót vagy az AKS-fürtöt.

Az AKS-fürt mindkét esetben nem látható nyilvánosan. A 2. lehetőséghez képest előfordulhat, hogy a bejövőforgalom-vezérlőre nincs szükség. A forgatókönyvtől és a konfigurációtól függően az API Management és a mikroszolgáltatások között továbbra is szükség lehet hitelesítésre. Ha például egy Service Mesh-t fogadnak el, az mindig kölcsönös TLS-hitelesítést igényel.

Profik:

• A legbiztonságosabb megoldás, mert az AKS-fürtnek nincs nyilvános végpontja
• Leegyszerűsíti a fürtkonfigurációt, mivel nincs nyilvános végpontja
• Az API Management és az AKS elrejtése a virtuális hálózaton belül a belső mód használatával
• A hálózati forgalom szabályozásának képessége azure-beli hálózati képességek, például hálózati biztonsági csoportok (NSG) használatával

Hátránya:

• Növeli az API Management virtuális hálózaton belüli üzembe helyezésének és konfigurálásának összetettségét

Következő lépések

• További információ az alkalmazások hálózati fogalmairól az AKS-ben
• További információ az API Management virtuális hálózatokkal való használatáról