Använda Azure API Management med mikrotjänster som distribuerats i Azure Kubernetes Service

GÄLLER FÖR: Alla API Management-nivåer

Mikrotjänster är perfekta för att skapa API:er. Med Azure Kubernetes Service (AKS) kan du snabbt distribuera och använda en mikrotjänstbaserad arkitektur i molnet. Du kan sedan använda Azure API Management (API Management ) för att publicera dina mikrotjänster som API:er för intern och extern förbrukning. I den här artikeln beskrivs alternativen för att distribuera API Management med AKS. Den förutsätter grundläggande kunskaper om Kubernetes, API Management och Azure-nätverk.

Bakgrund

När du publicerar mikrotjänster som API:er för förbrukning kan det vara svårt att hantera kommunikationen mellan mikrotjänsterna och klienterna som använder dem. Det finns en mängd olika övergripande problem som autentisering, auktorisering, begränsning, cachelagring, transformering och övervakning. Dessa problem är giltiga oavsett om mikrotjänsterna exponeras för interna eller externa klienter.

API Gateway-mönstret åtgärdar dessa problem. En API-gateway fungerar som en ytterdörr till mikrotjänsterna, frikopplar klienter från dina mikrotjänster, lägger till ytterligare ett säkerhetslager och minskar komplexiteten i dina mikrotjänster genom att ta bort bördan av att hantera problem med korsskärning.

Azure API Management är en nyckelfärdig lösning för att lösa dina API Gateway-behov. Du kan snabbt skapa en konsekvent och modern gateway för dina mikrotjänster och publicera dem som API:er. Som en api-hanteringslösning för hela livscykeln innehåller den även ytterligare funktioner, inklusive en självbetjäningsportal för utvecklare för API-identifiering, API-livscykelhantering och API-analys.

När de används tillsammans tillhandahåller AKS och API Management en plattform för att distribuera, publicera, skydda, övervaka och hantera dina mikrotjänstbaserade API:er. I den här artikeln går vi igenom några alternativ för att distribuera AKS tillsammans med API Management.

Kubernetes Services och API:er

I ett Kubernetes-kluster distribueras containrar i Poddar, som är tillfälliga och har en livscykel. När en arbetsnod dör går poddarna som körs på noden förlorade. Därför kan IP-adressen för en podd ändras när som helst. Vi kan inte lita på att den kommunicerar med podden.

För att lösa det här problemet introducerade Kubernetes begreppet tjänster. En Kubernetes Service är ett abstraktionslager som definierar en logikgrupp med poddar och möjliggör extern trafikexponering, belastningsutjämning och tjänstidentifiering för dessa poddar.

När vi är redo att publicera våra mikrotjänster som API:er via API Management måste vi fundera på hur vi ska mappa våra tjänster i Kubernetes till API:er i API Management. Det finns inga angivna regler. Det beror på hur du utformade och partitionerade dina affärsfunktioner eller domäner i mikrotjänster i början. Om poddarna bakom en tjänst till exempel ansvarar för alla åtgärder på en viss resurs (till exempel Kund) kan tjänsten mappas till ett API. Om åtgärder på en resurs partitioneras i flera mikrotjänster (till exempel GetOrder, PlaceOrder) kan flera tjänster aggregeras logiskt till ett enda API i API-hantering (se bild 1).

Mappningarna kan också utvecklas. Eftersom API Management skapar en fasad framför mikrotjänsterna kan vi omstrukturera och ändra storlek på våra mikrotjänster över tid.

Distribuera API Management framför AKS

Det finns några alternativ för att distribuera API Management framför ett AKS-kluster.

Även om ett AKS-kluster alltid distribueras i ett virtuellt nätverk (VNet), krävs ingen API Management-instans för att distribueras i ett virtuellt nätverk. När API Management inte finns i klustrets virtuella nätverk måste AKS-klustret publicera offentliga slutpunkter för API Management att ansluta till. I så fall finns det ett behov av att skydda anslutningen mellan API Management och AKS. Med andra ord måste vi se till att klustret endast kan nås uteslutande via API Management. Vi går igenom alternativen.

Alternativ 1: Exponera tjänster offentligt

Tjänster i ett AKS-kluster kan exponeras offentligt med hjälp av tjänsttyperna NodePort, LoadBalancer eller ExternalName. I det här fallet är tjänster tillgängliga direkt från offentligt Internet. När du har distribuerat API Management framför klustret måste vi se till att all inkommande trafik går via API Management genom att tillämpa autentisering i mikrotjänsterna. API Management kan till exempel innehålla en åtkomsttoken i varje begäran som görs till klustret. Varje mikrotjänst ansvarar för att verifiera token innan begäran bearbetas.

Det här kan vara det enklaste alternativet för att distribuera API Management framför AKS, särskilt om du redan har autentiseringslogik implementerad i dina mikrotjänster.

Proffsen:

• Enkel konfiguration på API Management-sidan eftersom den inte behöver matas in i klustrets virtuella nätverk
• Ingen ändring på AKS-sidan om tjänster redan är offentligt exponerade och autentiseringslogik redan finns i mikrotjänster

Nackdelar:

• Potentiell säkerhetsrisk på grund av offentlig synlighet för slutpunkter
• Ingen enskild startpunkt för inkommande klustertrafik
• Komplicerar mikrotjänster med duplicerad autentiseringslogik

Alternativ 2: Installera en ingresskontrollant

Även om alternativ 1 kan vara enklare, har det anmärkningsvärda nackdelar som nämns ovan. Om en API Management-instans inte finns i klustrets virtuella nätverk är ömsesidig TLS-autentisering (mTLS) ett robust sätt att säkerställa att trafiken är säker och betrodd i båda riktningarna mellan en API Management-instans och ett AKS-kluster.

Ömsesidig TLS-autentisering stöds internt av API Management och kan aktiveras i Kubernetes genom att installera en ingresskontrollant (bild 3). Därför utförs autentiseringen i ingresskontrollanten, vilket förenklar mikrotjänsterna. Dessutom kan du lägga till IP-adresserna för API Management i listan över tillåtna av Ingress för att se till att endast API Management har åtkomst till klustret.

Proffsen:

• Enkel konfiguration på API Management-sidan eftersom den inte behöver matas in i klustrets virtuella nätverk och mTLS stöds internt
• Centraliserar skyddet för inkommande klustertrafik på ingresskontrollantlagret
• Minskar säkerhetsrisken genom att minimera offentligt synliga klusterslutpunkter

Nackdelar:

• Ökar komplexiteten i klusterkonfigurationen på grund av extra arbete med att installera, konfigurera och underhålla ingresskontrollanten och hantera certifikat som används för mTLS
• Säkerhetsrisk på grund av offentlig synlighet för slutpunkter för ingresskontrollanter

När du publicerar API:er via API Management är det enkelt och vanligt att skydda åtkomsten till dessa API:er med hjälp av prenumerationsnycklar. Utvecklare som behöver använda publicerade API:er måste inkludera en giltig prenumerationsnyckel i HTTP-begäranden när de anropar dessa API:er. Annars avvisas anropen omedelbart av API Management-gatewayen. De vidarebefordras inte till serverdelstjänsterna.

För att få en prenumerationsnyckel för åtkomst till API:er krävs en prenumeration. En prenumeration är i princip en namngiven container för ett par prenumerationsnycklar. Utvecklare som behöver använda publicerade API:er kan hämta prenumerationer. Och de behöver inte godkännande från API-utgivare. API-utgivare kan också skapa prenumerationer direkt för API-konsumenter.

Alternativ 3: Distribuera APIM i klustrets virtuella nätverk

I vissa fall kan kunder med regelbegränsningar eller strikta säkerhetskrav hitta alternativ 1 och 2 som inte är genomförbara lösningar på grund av offentligt exponerade slutpunkter. I andra fall kan AKS-klustret och de program som använder mikrotjänsterna finnas i samma virtuella nätverk. Därför finns det ingen anledning att exponera klustret offentligt eftersom all API-trafik kommer att finnas kvar i det virtuella nätverket. I dessa scenarier kan du distribuera API Management till klustrets virtuella nätverk. API Management Developer- och Premium-nivåer stöder VNet-distribution.

Det finns två lägen för att distribuera API Management till ett virtuellt nätverk – externt och internt.

Om API-konsumenter inte finns i klustrets virtuella nätverk ska det externa läget (bild 4) användas. I det här läget matas API Management-gatewayen in i klustrets virtuella nätverk men är tillgänglig från offentligt Internet via en extern lastbalanserare. Det hjälper till att dölja klustret helt samtidigt som externa klienter fortfarande kan använda mikrotjänsterna. Dessutom kan du använda Azure-nätverksfunktioner som nätverkssäkerhetsgrupper (NSG) för att begränsa nätverkstrafiken.

Om alla API-konsumenter finns i klustrets virtuella nätverk kan det interna läget (bild 5) användas. I det här läget matas API Management-gatewayen in i klustrets virtuella nätverk och är endast tillgänglig från det här virtuella nätverket via en intern lastbalanserare. Det finns inget sätt att nå API Management-gatewayen eller AKS-klustret från offentligt Internet.

I båda fallen är AKS-klustret inte offentligt synligt. Jämfört med alternativ 2 kanske ingresskontrollanten inte är nödvändig. Beroende på ditt scenario och din konfiguration kan autentisering fortfarande krävas mellan API Management och dina mikrotjänster. Om till exempel ett Service Mesh antas kräver det alltid ömsesidig TLS-autentisering.

Proffsen:

• Det säkraste alternativet eftersom AKS-klustret inte har någon offentlig slutpunkt
• Förenklar klusterkonfigurationen eftersom den inte har någon offentlig slutpunkt
• Möjlighet att dölja både API Management och AKS i det virtuella nätverket med hjälp av internt läge
• Möjlighet att styra nätverkstrafik med hjälp av Azure-nätverksfunktioner, till exempel nätverkssäkerhetsgrupper (NSG)

Nackdelar:

• Ökar komplexiteten i att distribuera och konfigurera API Management för att fungera i det virtuella nätverket

Nästa steg

• Läs mer om nätverksbegrepp för program i AKS
• Läs mer om hur du använder API Management med virtuella nätverk