Distribuera en gateway med egen värd till Kubernetes

Artikel
10/09/2021
5 minuter för att läsa

Den här artikeln beskriver stegen för att distribuera gatewaykomponenten med egen värd i Azure API Management till ett Kubernetes-kluster.

Anteckning

Du kan också distribuera en gateway med egen värd till Azure Arc Kubernetes-kluster som ett klustertillägg.

Förutsättningar

Slutför följande snabbstart: Skapa en Azure API Management instans.
Skapa ett Kubernetes-kluster.

Tips

Kluster med en nod fungerar bra för utveckling och utvärdering. Använd Kubernetes-certifierade kluster med flera noder lokalt eller i molnet för produktionsarbetsbelastningar.
Etablera en gatewayresurs med egen värd i din API Management instans.

Distribuera till Kubernetes

Välj Gateways (Gatewayer) under Deployment and infrastructure (Distribution och infrastruktur).
Välj den gatewayresurs med egen värd som du vill distribuera.
Välj Distribution.
En åtkomsttoken i textrutan Token genererades automatiskt åt dig, baserat på standardvärdena Förfallo- och Hemlighetsnyckel. Om det behövs väljer du värden i en eller båda kontrollerna för att generera en ny token.
Välj fliken Kubernetes under Distributionsskript.
Välj <gateway-name> .yml-fillänken och ladda ned YAML-filen.
Välj kopieringsikonen i det nedre högra hörnet i textrutan Distribuera för att kubectl spara kommandona i Urklipp.
Klistra in kommandon i terminalfönstret (eller kommandofönstret). Det första kommandot skapar en Kubernetes-hemlighet som innehåller den åtkomsttoken som genererades i steg 4. Det andra kommandot tillämpar konfigurationsfilen som laddades ned i steg 6 på Kubernetes-klustret och förväntar sig att filen finns i den aktuella katalogen.
Kör kommandona för att skapa nödvändiga Kubernetes-objekt i standardnamnrymden och starta gateway-poddar med egen värd från containeravbildningen som laddats ned från Microsoft Container Registry.
Kör följande kommando för att kontrollera om distributionen lyckades. Observera att det kan ta lite tid innan alla objekt skapas och att poddarna initieras.
```
kubectl get deployments
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
<gateway-name>   1/1     1            1           18s
```

Kör följande kommando för att kontrollera om tjänsten har skapats. Observera att tjänst-IP-adresser och portar skiljer sig åt.

kubectl get services
NAME             TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
<gateway-name>   LoadBalancer   10.99.236.168   <pending>     80:31620/TCP,443:30456/TCP   9m1s

Gå tillbaka till Azure Portal och välj Översikt.
Bekräfta att Status visar en grön bockmarkering följt av ett nodantal som matchar antalet repliker som anges i YAML-filen. Den här statusen innebär att de distribuerade lokala gateway-poddarna kommunicerar med API Management tjänsten och har ett regelbundet "pulsslag".

Tips

Kör kommandot kubectl logs deployment/<gateway-name> för att visa loggar från en slumpmässigt vald podd om det finns fler än en. Kör kubectl logs -h för en fullständig uppsättning kommandoalternativ, till exempel hur du visar loggar för en specifik podd eller container.

Överväganden för produktionsdistribution

Åtkomsttoken

Utan en giltig åtkomsttoken kan en gateway med egen värd 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 API-åtgärden för hantering för att generera en ny token. Information om hur du hanterar Kubernetes-hemligheter finns på Kubernetes webbplats.

Namnområde

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

I Azure Portal kommandon för att skapa gatewayresurser med egen värd i standardnamnrymden. Det här namnområdet skapas automatiskt, finns i alla 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 två.

Som standard distribueras en gateway med egen värd med distributionsstrategin 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.

Containerresurser

Som standard anger YAML-filen i Azure Portal inte containerresursbegäranden.

Det går inte att tillförlitligt 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 är på spel, 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.
Nyttolastens storlek och om nyttolaster buffrats eller strömmas.
Svarstid för backend-tjänsten.

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

Containeravbildningstagg

YAML-filen som finns i Azure Portal använder taggen latest. Den här taggen refererar alltid till den senaste versionen av containeravbildningen för en gateway med egen värd.

Ö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.

DNS-princip

DNS-namnmatchning spelar en viktig roll i en gateway med egen värd möjligheten att ansluta till beroenden i Azure och skicka API-anrop till servertjänster.

YAML-filen som finns i Azure Portal tillämpar standardprincipen ClusterFirst. Den här principen gör att namnmatchningsbegäranden som inte matchas av klustrets DNS vidarebefordras till den överordnade DNS-server som ärvts 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 finns i Azure Portal externalTrafficPolicy anger i Service-objektet 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ämnt antal gateway-poddar per nod.

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 för i config.service.endpoint <gateway-name> .yaml-filen för att ersätta standarddomännamnet med det anpassade domännamnet. Kontrollera att hanteringsslutpunkten kan nås från podden för den egen värdbaserade gatewayen i Kubernetes-klustret.

I det här scenariot, om SSL-certifikatet som används av hanteringsslutpunkten inte är signerat av ett välkänt CA-certifikat, måste du se till att CA-certifikatet är betrott av podden för den lokala gatewayen.

Konfigurationssäkerhetskopiering

Mer information om gatewaybeteende med egen värd vid ett tillfälligt avbrott i Azure-anslutningenfinns i Översikt över gateway med egen värd.

Konfigurera en lokal lagringsvolym för gatewaycontainern med egen värd, 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. Volymens monteringssökväg måste vara /apim/config . Se ett exempel på GitHub. Mer information om lagring i Kubernetes finns på Kubernetes webbplats.

Lokala loggar och mått

Den lokala 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 bryts avbryts flödet av telemetri till Azure och data går förlorade under avbrottet. Överväg att 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.

Nästa steg

Mer information om gatewayen med egen värd finns i Översikt över gateway med egen värd.
Lär dig hur du API Management en gateway med egen värd till Azure Arc Kubernetes-kluster.