Použití služby Azure API Management s mikroslužbami nasazenými ve službě Azure Kubernetes Service

PLATÍ PRO: Všechny úrovně služby API Management

Mikroslužby jsou ideální pro vytváření rozhraní API. Pomocí služby Azure Kubernetes Service (AKS) můžete rychle nasadit a provozovat architekturu založenou na mikroslužbách v cloudu. Pak můžete využít Azure API Management (API Management) k publikování mikroslužeb jako rozhraní API pro interní a externí spotřebu. Tento článek popisuje možnosti nasazení služby API Management s AKS. Předpokládá základní znalosti kubernetes, služby API Management a sítí Azure.

Pozadí

Při publikování mikroslužeb jako rozhraní API pro spotřebu může být obtížné spravovat komunikaci mezi mikroslužbami a klienty, kteří je využívají. Existuje mnoho různých aspektů, jako je ověřování, autorizace, omezování, ukládání do mezipaměti, transformace a monitorování. Tyto obavy jsou platné bez ohledu na to, jestli jsou mikroslužby vystavené interním nebo externím klientům.

Vzor služby API Gateway tyto obavy řeší. Brána rozhraní API slouží jako přední dveře mikroslužeb, odděluje klienty od vašich mikroslužeb, přidává další vrstvu zabezpečení a snižuje složitost mikroslužeb tím, že odstraňuje zátěž při řešení problémů s křížovým dělením.

Azure API Management je řešení na klíč, které řeší potřeby brány rozhraní API. Pro mikroslužby můžete rychle vytvořit konzistentní a moderní bránu a publikovat je jako rozhraní API. Jako řešení pro správu rozhraní API pro celý životní cyklus poskytuje také další funkce, včetně samoobslužného vývojářského portálu pro zjišťování rozhraní API, správy životního cyklu rozhraní API a analýzy rozhraní API.

Při společném použití poskytují AKS a API Management platformu pro nasazování, publikování, zabezpečení, monitorování a správu rozhraní API založených na mikroslužbách. V tomto článku si projdeme několik možností nasazení AKS ve spojení se službou API Management.

Kubernetes Services a rozhraní API

V clusteru Kubernetes se kontejnery nasazují v podech, které jsou dočasné a mají životní cyklus. Když pracovní uzel zemře, dojde ke ztrátě podů spuštěných na uzlu. Ip adresa podu se proto může kdykoli změnit. Nemůžeme spoléhat na to, aby komunikoval s podem.

K vyřešení tohoto problému kubernetes zavedl koncept služeb. Kubernetes Service je abstrakční vrstva, která definuje skupinu logiky podů a umožňuje externímu vystavení provozu, vyrovnávání zatížení a zjišťování služeb pro tyto pody.

Až budeme připraveni publikovat naše mikroslužby jako rozhraní API prostřednictvím služby API Management, musíme přemýšlet o tom, jak mapovat naše služby v Kubernetes na rozhraní API ve službě API Management. Neexistují žádná nastavená pravidla. Záleží na tom, jak jste na začátku navrhli a rozdělili své obchodní funkce nebo domény do mikroslužeb. Pokud jsou například pody za službou zodpovědné za všechny operace s daným prostředkem (například zákazníkem), může být služba mapována na jedno rozhraní API. Pokud jsou operace s prostředkem rozdělené do několika mikroslužeb (například GetOrder, PlaceOrder), může být více služeb logicky agregováno do jednoho rozhraní API ve službě API Management (viz obr. 1).

Mapování se také mohou vyvíjet. Vzhledem k tomu, že služba API Management vytváří fasádu před mikroslužbami, umožňuje refaktoring a správnou velikost mikroslužeb v průběhu času.

Nasazení služby API Management před AKS

Před clusterem AKS existuje několik možností nasazení služby API Management.

I když je cluster AKS vždy nasazený ve virtuální síti, instance služby API Management se nevyžaduje k nasazení ve virtuální síti. Pokud se služba API Management nenachází ve virtuální síti clusteru, musí cluster AKS publikovat veřejné koncové body pro službu API Management, ke které se má připojit. V takovém případě je potřeba zabezpečit připojení mezi službou API Management a AKS. Jinými slovy, musíme zajistit, aby ke clusteru bylo možné přistupovat výhradně prostřednictvím služby API Management. Pojďme si projít možnosti.

Možnost 1: Zveřejnění služeb veřejně

Služby v clusteru AKS je možné veřejně zpřístupnit pomocí typů služeb NodePort, LoadBalancer nebo ExternalName. V takovém případě jsou služby přístupné přímo z veřejného internetu. Po nasazení služby API Management před cluster musíme zajistit, aby veškerý příchozí provoz procházel službou API Management pomocí ověřování v mikroslužbách. Služba API Management může například do každého požadavku vytvořeného v clusteru zahrnout přístupový token. Každá mikroslužba zodpovídá za ověření tokenu před zpracováním požadavku.

To může být nejjednodušší možnost nasazení služby API Management před AKS, zejména pokud už máte logiku ověřování implementovanou ve svých mikroslužbách.

Profesionálové:

• Snadná konfigurace na straně služby API Management, protože nemusí být vložena do virtuální sítě clusteru.
• Pokud služby jsou veřejně přístupné a logika ověřování již v mikroslužbách existuje, není na straně AKS žádná změna.

Nevýhody:

• Potenciální riziko zabezpečení z důvodu veřejné viditelnosti koncových bodů
• Žádný vstupní bod pro příchozí provoz clusteru
• Komplikuje mikroslužby s duplicitní logikou ověřování.

Možnost 2: Instalace kontroleru příchozího přenosu dat

I když možnost 1 může být jednodušší, má velmi vhodné nevýhody, jak je uvedeno výše. Pokud se instance služby API Management nenachází ve virtuální síti clusteru, je vzájemné ověřování TLS (mTLS) robustním způsobem, jak zajistit, aby byl provoz zabezpečený a důvěryhodný v obou směrech mezi instancí služby API Management a clusterem AKS.

Služba API Management nativně podporuje vzájemné ověřování TLS a dá se povolit v Kubernetes instalací kontroleru příchozího přenosu dat (obr. 3). V důsledku toho se ověřování provede v kontroleru příchozího přenosu dat, což zjednodušuje mikroslužby. Kromě toho můžete přidat IP adresy služby API Management do seznamu povolených příchozím přenosem dat, abyste měli jistotu, že ke clusteru má přístup jenom služba API Management. Pokud se používá úroveň API Management Úrovně Premium nebo Úroveň Standard V2, můžete dosáhnout izolace na úrovni sítě.

Profesionálové:

• Snadná konfigurace na straně služby API Management, protože nemusí být vložena do virtuální sítě clusteru a mTLS je nativně podporována.
• Centralizuje ochranu příchozího provozu clusteru ve vrstvě kontroleru příchozího přenosu dat.
• Snižuje riziko zabezpečení minimalizací veřejně viditelných koncových bodů clusteru.

Nevýhody:

• Zvyšuje složitost konfigurace clusteru kvůli dodatečné práci při instalaci, konfiguraci a údržbě kontroleru příchozího přenosu dat a správě certifikátů používaných pro mTLS.
• Bezpečnostní riziko způsobené veřejným viditelností koncových bodů kontroleru příchozího přenosu dat, pokud se nepoužívá úroveň API Management Standard v2 nebo Premium.

Když publikujete rozhraní API prostřednictvím služby API Management, je snadné a běžné zabezpečit přístup k těmto rozhraním API pomocí klíčů předplatného. Vývojáři, kteří potřebují využívat publikovaná rozhraní API, musí při volání těchto rozhraní API zahrnout platný klíč předplatného v požadavcích HTTP. Jinak se volání okamžitě zamítnou bránou služby API Management. Nepřesílají se do back-endových služeb.

K získání klíče předplatného pro přístup k rozhraním API se vyžaduje předplatné. Předplatné je v podstatě pojmenovaný kontejner pro dvojici klíčů předplatného. Vývojáři, kteří potřebují využívat publikovaná rozhraní API, můžou získat předplatná. A nepotřebují schválení od vydavatelů rozhraní API. Vydavatelé rozhraní API můžou také vytvářet předplatná přímo pro uživatele rozhraní API.

Možnost 3: Nasazení služby APIM uvnitř virtuální sítě clusteru

V některých případech můžou zákazníci s zákonnými omezeními nebo striktní požadavky na zabezpečení najít řešení s možností 1 a 2 kvůli veřejně vystaveným koncovým bodům. V jiných se cluster AKS a aplikace, které využívají mikroslužby, můžou nacházet ve stejné virtuální síti, a proto není důvod zveřejnit cluster veřejně, protože veškerý provoz rozhraní API zůstane ve virtuální síti. Pro tyto scénáře můžete nasadit službu API Management do virtuální sítě clusteru. Úrovně API Management Developer a Premium podporují nasazení virtuální sítě.

Existují dva režimy nasazení služby API Management do virtuální sítě – externí a interní.

Pokud se spotřebitelé rozhraní API nenasadí do virtuální sítě clusteru, je třeba použít externí režim (obr. 4). V tomto režimu se brána služby API Management vloží do virtuální sítě clusteru, ale přístupná z veřejného internetu prostřednictvím externího nástroje pro vyrovnávání zatížení. Pomáhá zcela skrýt cluster a zároveň umožňuje externím klientům využívat mikroslužby. Kromě toho můžete k omezení síťového provozu použít síťové funkce Azure, jako jsou skupiny zabezpečení sítě (NSG).

Pokud se všichni příjemci rozhraní API nacházejí ve virtuální síti clusteru, je možné použít interní režim (obr. 5). V tomto režimu se brána služby API Management vloží do virtuální sítě clusteru a přístupná jenom z této virtuální sítě prostřednictvím interního nástroje pro vyrovnávání zatížení. Není žádný způsob, jak se dostat k bráně služby API Management nebo ke clusteru AKS z veřejného internetu.

V obou případech není cluster AKS veřejně viditelný. Ve srovnání s možností 2 nemusí být kontroler příchozího přenosu dat nutný. V závislosti na vašem scénáři a konfiguraci může být ověřování stále potřeba mezi službou API Management a vašimi mikroslužbami. Pokud je například přijata služba Service Mesh, vždy vyžaduje vzájemné ověřování TLS.

Profesionálové:

• Nejbezpečnější možnost, protože cluster AKS nemá žádný veřejný koncový bod
• Zjednodušuje konfiguraci clusteru, protože nemá žádný veřejný koncový bod.
• Možnost skrýt službu API Management i AKS ve virtuální síti pomocí interního režimu
• Schopnost řídit síťový provoz pomocí síťových funkcí Azure, jako jsou skupiny zabezpečení sítě (NSG)

Nevýhody:

• Zvyšuje složitost nasazení a konfigurace služby API Management tak, aby fungovala v rámci virtuální sítě.

Další kroky

• Další informace o konceptech sítě pro aplikace v AKS
• Další informace o používání služby API Management s virtuálními sítěmi