Vägledning för att köra en lokalt installerad gateway på Kubernetes i produktion

  • Artikel

GÄLLER FÖR: Utvecklare | Premium

För att kunna köra den lokala gatewayen i produktion finns det olika aspekter att tänka på. Den bör till exempel distribueras på ett sätt med hög tillgänglighet, använda konfigurationssäkerhetskopior för att hantera tillfälliga frånkopplingar och många fler.

Den här artikeln innehåller vägledning om hur du kör en lokalt installerad gateway på Kubernetes för produktionsarbetsbelastningar för att säkerställa att den körs smidigt och tillförlitligt.

Viktigt!

Stöd för azure API Management med egen värdbaserad gateway version 0 och version 1-containeravbildningar upphör den 1 oktober 2023, tillsammans med motsvarande Konfigurations-API v1. Använd vår migreringsguide för att använda lokalt installerad gateway v2.0.0 eller senare med Configuration API v2. Läs mer i vår utfasningsdokumentation

Åtkomsttoken

Utan en giltig åtkomsttoken kan en lokalt installerad gateway inte komma åt och ladda ned konfigurationsdata från slutpunkten för den associerade API Management-tjänsten. Åtkomsttoken kan vara giltig i högst 30 dagar. Det måste återskapas och klustret konfigureras med en ny token, antingen manuellt eller via automatisering innan det upphör att gälla.

När du automatiserar tokenuppdateringen använder du den här hanterings-API-åtgärden för att generera en ny token. Information om hur du hanterar Kubernetes-hemligheter finns på Kubernetes webbplats.

Dricks

Du kan också distribuera den lokalt installerade gatewayen till Kubernetes och aktivera autentisering till API Management-instansen med hjälp av Microsoft Entra-ID.

Automatisk skalning

Vi ger vägledning om det minsta antalet repliker för den lokalt installerade gatewayen, men vi rekommenderar att du använder automatisk skalning för den lokalt installerade gatewayen för att möta efterfrågan på din trafik mer proaktivt.

Det finns två sätt att autoskala den lokalt installerade gatewayen vågrätt:

  • Autoskalning baserat på resursanvändning (CPU och minne)
  • Autoskalning baserat på antalet begäranden per sekund

Detta är möjligt via inbyggda Kubernetes-funktioner eller med kubernetes händelsedriven autoskalning (KEDA). KEDA är ett CNCF-inkubationsprojekt som strävar efter att göra automatisk skalning av program enkelt.

Kommentar

KEDA är en teknik med öppen källkod som inte stöds av Azure-supporten och som måste drivas av kunder.

Resursbaserad autoskalning

Med Kubernetes kan du autoskala den lokalt installerade gatewayen baserat på resursanvändning med hjälp av en horisontell podd autoskalning. Det gör att du kan definiera tröskelvärden för processor och minne och antalet repliker som ska skalas ut eller in.

Ett alternativ är att använda Kubernetes Händelsedriven autoskalning (KEDA) så att du kan skala arbetsbelastningar baserat på en mängd olika skalare, inklusive CPU och minne.

Dricks

Om du redan använder KEDA för att skala andra arbetsbelastningar rekommenderar vi att du använder KEDA som en enhetlig app autoskalning. Om så inte är fallet rekommenderar vi starkt att du förlitar oss på de inbyggda Kubernetes-funktionerna via horisontell podd-autoskalning.

Trafikbaserad autoskalning

Kubernetes tillhandahåller ingen out-of-the-box-mekanism för trafikbaserad autoskalning.

Kubernetes Händelsedriven autoskalning (KEDA) innehåller några olika sätt som kan hjälpa dig med trafikbaserad autoskalning:

  • Du kan skala baserat på mått från en Kubernetes-ingress om de är tillgängliga i Prometheus eller Azure Monitor med hjälp av en out-of-the-box-skalning
  • Du kan installera HTTP-tillägg, som är tillgängligt i betaversionen, och skalar baserat på antalet begäranden per sekund.

Konfigurationssäkerhetskopiering

Konfigurera en lokal lagringsvolym för den lokala gatewaycontainern så att den kan spara en säkerhetskopia av den senaste nedladdade konfigurationen. Om anslutningen är nere kan lagringsvolymen använda säkerhetskopian vid omstart. Volymmonteringssökvägen måste vara /apim/config och måste ägas av grupp-ID 1001. Se ett exempel på GitHub. Mer information om lagring i Kubernetes finns på Kubernetes webbplats. Information om hur du ändrar ägarskap för en monterad sökväg finns i securityContext.fsGroup inställningen på Kubernetes webbplats.

Kommentar

Mer information om beteende för lokalt installerad gateway i närvaro av ett tillfälligt avbrott i Azure-anslutningen finns i Översikt över lokalt installerad gateway.

Tagg för containeravbildning

YAML-filen som tillhandahålls i Azure-portalen använder den senaste taggen. Den här taggen refererar alltid till den senaste versionen av den lokalt installerade gatewaycontaineravbildningen.

Överväg att använda en specifik versionstagg i produktion för att undvika oavsiktlig uppgradering till en nyare version.

Du kan ladda ned en fullständig lista över tillgängliga taggar.

Dricks

När du installerar med Helm optimeras avbildningstaggning åt dig. Helm-diagrammets programversion fäster gatewayen till en viss version och förlitar sig inte på latest.

Läs mer om hur du installerar en lokalt installerad API Management-gateway på Kubernetes med Helm.

Containerresurser

Som standard anger YAML-filen som tillhandahålls i Azure-portalen inte begäranden om containerresurser.

Det är omöjligt att på ett tillförlitligt sätt förutsäga och rekommendera mängden processor- och minnesresurser per container och antalet repliker som krävs för att stödja en viss arbetsbelastning. Många faktorer spelar in, till exempel:

  • Specifik maskinvara som klustret körs på.
  • Närvaro och typ av virtualisering.
  • Antal och frekvens för samtidiga klientanslutningar.
  • Begärandefrekvens.
  • Typ och antal konfigurerade principer.
  • Nyttolaststorlek och om nyttolaster buffrats eller strömmats.
  • Svarstid för serverdelstjänsten.

Vi rekommenderar att du ställer in resursbegäranden på två kärnor och 2 GiB som utgångspunkt. Utför ett belastningstest och skala upp/ut eller ned/in baserat på resultaten.

Anpassade domännamn och SSL-certifikat

Om du använder anpassade domännamn för API Management-slutpunkterna, särskilt om du använder ett anpassat domännamn för hanteringsslutpunkten, kan du behöva uppdatera värdet config.service.endpoint för i< filen gateway-name.yaml> för att ersätta standarddomännamnet med det anpassade domännamnet. Kontrollera att hanteringsslutpunkten kan nås från podden för den lokalt installerade gatewayen i Kubernetes-klustret.

Om SSL-certifikatet som används av hanteringsslutpunkten inte är signerat av ett välkänt CA-certifikat i det här scenariot måste du se till att CERTIFIKATutfärdarcertifikatet är betrott av podden för den lokalt installerade gatewayen.

Kommentar

Med den lokala gatewayen v2 tillhandahåller API Management en ny konfigurationsslutpunkt: <apim-service-name>.configuration.azure-api.net. Anpassade värdnamn stöds för den här slutpunkten och kan användas i stället för standardvärdnamnet.

DNS-princip

DNS-namnmatchning spelar en viktig roll i en lokalt installerad gateways möjlighet att ansluta till beroenden i Azure och skicka API-anrop till serverdelstjänster.

YAML-filen som tillhandahålls i Azure-portalen tillämpar standardprincipen ClusterFirst . Den här principen gör att namnmatchningsbegäranden som inte matchas av klustrets DNS vidarebefordras till den överordnade DNS-servern som ärvs från noden.

Mer information om namnmatchning i Kubernetes finns på Kubernetes webbplats. Överväg att anpassa DNS-principen eller DNS-konfigurationen efter behov för konfigurationen.

Princip för extern trafik

YAML-filen som anges i fältet Azure-portaluppsättningar externalTrafficPolicy i serviceobjektet till Local. Detta bevarar anroparens IP-adress (tillgänglig i begärandekontexten) och inaktiverar belastningsutjämning mellan noder, vilket eliminerar nätverkshopp som orsakas av den. Tänk på att den här inställningen kan orsaka asymmetrisk distribution av trafik i distributioner med ojämlikt antal gatewaypoddar per nod.

Hög tillgänglighet

Den lokalt installerade gatewayen är en viktig komponent i infrastrukturen och måste vara mycket tillgänglig. Ett fel kan dock inträffa.

Överväg att skydda den lokala gatewayen mot störningar.

Dricks

När du installerar med Helm kan du enkelt aktivera schemaläggning med hög tillgänglighet genom att aktivera konfigurationsalternativet highAvailability.enabled .

Läs mer om hur du installerar en lokalt installerad API Management-gateway på Kubernetes med Helm.

Skydda mot nodfel

Om du vill förhindra att påverkas på grund av datacenter- eller nodfel kan du överväga att använda ett Kubernetes-kluster som använder tillgänglighetszoner för att uppnå hög tillgänglighet på nodnivå.

Med tillgänglighetszoner kan du schemalägga den lokala gatewayens podd på noder som är spridda över zonerna med hjälp av:

Kommentar

Om du använder Azure Kubernetes Service lär du dig hur du använder tillgänglighetszoner i den här artikeln.

Skydda mot poddstörningar

Poddar kan uppleva avbrott på grund av olika orsaker, till exempel manuell borttagning av poddar, nodunderhåll osv.

Överväg att använda poddstörningsbudgetar för att framtvinga ett minsta antal poddar som ska vara tillgängliga vid en viss tidpunkt.

HTTP(S)-proxy

Den lokalt installerade gatewayen har stöd för HTTP(S)-proxy med hjälp av de traditionella HTTP_PROXYmiljövariablerna och HTTPS_PROXYNO_PROXY .

När den har konfigurerats använder den lokalt installerade gatewayen automatiskt proxyn för alla utgående HTTP(S) begäranden till serverdelstjänsterna.

Från och med version 2.1.5 eller senare tillhandahåller den lokalt installerade gatewayen observerbarhet relaterad till proxybegäran:

  • API Inspector visar ytterligare steg när HTTP(S) proxy används och dess relaterade interaktioner.
  • Utförliga loggar tillhandahålls för att ge en indikation på beteendet för begärandeproxyn.

Kommentar

På grund av ett känt problem med HTTP-proxyservrar med grundläggande autentisering stöds inte verifiering av återkallade certifikat (CRL). Läs mer i våra inställningar för lokalt installerad gateway som refererar till hur du konfigurerar den på rätt sätt.

Varning

Kontrollera att infrastrukturkraven har uppfyllts och att den lokalt installerade gatewayen fortfarande kan ansluta till dem eller att vissa funktioner inte fungerar korrekt.

Lokala loggar och mått

Den lokalt installerade gatewayen skickar telemetri till Azure Monitor och Azure Application Insights enligt konfigurationsinställningarna i den associerade API Management-tjänsten. När anslutningen till Azure tillfälligt går förlorad avbryts telemetriflödet till Azure och data går förlorade under driftstoppet.

Överväg att använda Azure Monitor Container Insights för att övervaka dina containrar eller konfigurera lokal övervakning för att säkerställa möjligheten att observera API-trafik och förhindra telemetriförlust vid avbrott i Azure-anslutningen.

Namnområde

Kubernetes-namnområden hjälper dig att dela upp ett kluster mellan flera team, projekt eller program. Namnområden ger ett omfång för resurser och namn. De kan associeras med en resurskvot och åtkomstkontrollprinciper.

Azure-portalen innehåller kommandon för att skapa gatewayresurser med egen värd i standardnamnområdet . Det här namnområdet skapas automatiskt, finns i varje kluster och kan inte tas bort. Överväg att skapa och distribuera en gateway med egen värd till ett separat namnområde i produktion.

Antal repliker

Det minsta antalet repliker som är lämpliga för produktion är tre, helst i kombination med högtillgänglig schemaläggning av instanserna.

Som standard distribueras en lokalt installerad gateway med en distributionsstrategi för RollingUpdate. Granska standardvärdena och överväg att uttryckligen ange fälten maxUnavailable och maxSurge , särskilt när du använder ett högt replikantal.

Prestanda

Vi rekommenderar att du minskar containerloggarna till varningar (warn) för att förbättra prestandan. Läs mer i vår konfigurationsreferens för lokalt installerad gateway.

Begränsning av begäran

Begränsning av begäranden i en lokalt installerad gateway kan aktiveras med hjälp av principen för API Management-hastighetsbegränsning eller hastighetsgräns per nyckel. Konfigurera antal hastighetsbegränsningar som ska synkroniseras mellan gatewayinstanser mellan klusternoder genom att exponera följande portar i Kubernetes-distributionen för instansidentifiering:

  • Port 4290 (UDP) för synkronisering av hastighetsbegränsning
  • Port 4291 (UDP) för att skicka pulsslag till andra instanser

Kommentar

Frekvensgränsantal i en lokalt installerad gateway kan konfigureras för att synkronisera lokalt (bland gatewayinstanser mellan klusternoder), till exempel via Helm-diagramdistribution för Kubernetes eller med hjälp av Distributionsmallar för Azure-portalen. Frekvensgränsantal synkroniseras dock inte med andra gatewayresurser som konfigurerats i API Management-instansen, inklusive den hanterade gatewayen i molnet.

Säkerhet

Den lokalt installerade gatewayen kan köras som icke-rot i Kubernetes så att kunderna kan köra gatewayen på ett säkert sätt.

Här är ett exempel på säkerhetskontexten för den lokalt installerade gatewaycontainern:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

Varning

Det går inte att köra den lokalt installerade gatewayen med skrivskyddat filsystem (readOnlyRootFilesystem: true).

Varning

När du använder lokala CA-certifikat måste den lokalt installerade gatewayen köras med användar-ID (UID) 1001 för att kunna hantera CA-certifikaten, annars startar inte gatewayen.

Nästa steg