Richtlijnen voor het uitvoeren van zelf-hostende gateway op Kubernetes in productie

  • Artikel

VAN TOEPASSING OP: Ontwikkelaar | Premium

Om de zelf-hostende gateway in productie uit te voeren, zijn er verschillende aspecten waar u rekening mee moet houden. Het moet bijvoorbeeld op een maximaal beschikbare manier worden geïmplementeerd, configuratieback-ups gebruiken om tijdelijke verbroken verbindingen en nog veel meer af te handelen.

Dit artikel bevat richtlijnen voor het uitvoeren van zelf-hostende gateways op Kubernetes voor productieworkloads om ervoor te zorgen dat deze probleemloos en betrouwbaar wordt uitgevoerd.

Belangrijk

Ondersteuning voor zelf-hostende gatewayversie 0 en versie 1 van Azure API Management eindigt op 1 oktober 2023, samen met de bijbehorende Configuratie-API v1. Gebruik onze migratiehandleiding voor het gebruik van zelf-hostende gateway v2.0.0 of hoger met configuration-API v2. Meer informatie vindt u in onze documentatie over afschaffing

Toegangstoken

Zonder een geldig toegangstoken kan een zelf-hostende gateway geen configuratiegegevens openen en downloaden vanaf het eindpunt van de bijbehorende API Management-service. Het toegangstoken kan maximaal 30 dagen geldig zijn. Het moet opnieuw worden gegenereerd en het cluster dat is geconfigureerd met een nieuw token, handmatig of via automatisering voordat het verloopt.

Wanneer u het vernieuwen van tokens automatiseert, gebruikt u deze beheer-API-bewerking om een nieuw token te genereren. Zie de Kubernetes-website voor informatie over het beheren van Kubernetes-geheimen.

Tip

U kunt ook de zelf-hostende gateway implementeren in Kubernetes en verificatie inschakelen voor het API Management-exemplaar met behulp van Microsoft Entra-id.

Automatisch schalen

Hoewel we richtlijnen bieden voor het minimale aantal replica's voor de zelf-hostende gateway, raden we u aan om automatisch schalen te gebruiken voor de zelf-hostende gateway om proactief aan de vraag van uw verkeer te voldoen.

Er zijn twee manieren om de zelf-hostende gateway horizontaal te schalen:

  • Automatisch schalen op basis van resourcegebruik (CPU en geheugen)
  • Automatisch schalen op basis van het aantal aanvragen per seconde

Dit is mogelijk via systeemeigen Kubernetes-functionaliteit of met behulp van Kubernetes Gebeurtenisgestuurde Automatische schaalaanpassing (KEDA). KEDA is een CNCF Incubation-project dat ernaar streeft om automatisch schalen van toepassingen eenvoudig te maken.

Notitie

KEDA is een opensource-technologie die niet wordt ondersteund door ondersteuning voor Azure en moet worden beheerd door klanten.

Automatisch schalen op basis van resources

Met Kubernetes kunt u de zelf-hostende gateway automatisch schalen op basis van resourcegebruik met behulp van een horizontale automatische schaalaanpassing voor pods. Hiermee kunt u CPU- en geheugendrempels definiëren en het aantal replica's dat moet worden uitgeschaald of ingeschaald.

Een alternatief is om Kubernetes Gebeurtenisgestuurde Automatische schaalaanpassing (KEDA) te gebruiken, zodat u workloads kunt schalen op basis van verschillende schaalders, waaronder CPU en geheugen.

Tip

Als u KEDA al gebruikt om andere workloads te schalen, raden we u aan KEDA te gebruiken als een geïntegreerde automatische schaalaanpassing van apps. Als dat niet het geval is, raden we sterk aan om te vertrouwen op de systeemeigen Kubernetes-functionaliteit via horizontale automatische schaalaanpassing van pods.

Automatisch schalen op basis van verkeer

Kubernetes biedt geen out-of-the-box mechanisme voor automatisch schalen op basis van verkeer.

Kubernetes Gebeurtenisgestuurde Automatische schaalaanpassing (KEDA) biedt een aantal manieren om te helpen met automatisch schalen op basis van verkeer:

  • U kunt schalen op basis van metrische gegevens van een Kubernetes-toegangsbeheerobject als deze beschikbaar zijn in Prometheus of Azure Monitor met behulp van een out-of-the-box scaler
  • U kunt de HTTP-invoegtoepassing installeren, die beschikbaar is in de bètaversie en schaalt op basis van het aantal aanvragen per seconde.

Configuratieback-up

Configureer een lokaal opslagvolume voor de zelf-hostende gatewaycontainer, zodat er een back-upkopie van de meest recente gedownloade configuratie kan worden bewaard. Als de verbinding is uitgeschakeld, kan het opslagvolume de back-upkopie gebruiken bij het opnieuw opstarten. Het pad voor het koppelen van het volume moet zijn /apim/config en moet eigendom zijn van de groeps-id 1001. Bekijk een voorbeeld op GitHub. Zie de Kubernetes-website voor meer informatie over opslag in Kubernetes. Als u het eigendom van een gekoppeld pad wilt wijzigen, raadpleegt u de securityContext.fsGroup instelling op de Kubernetes-website.

Notitie

Zie het overzicht van zelf-hostende gateways voor meer informatie over het gedrag van zelf-hostende gateways in aanwezigheid van een tijdelijke Azure-connectiviteitsstoring.

Containerinstallatiekopieëntag

Het YAML-bestand dat is opgegeven in Azure Portal maakt gebruik van de meest recente tag. Deze tag verwijst altijd naar de meest recente versie van de zelf-hostende gatewaycontainerinstallatiekopie.

Overweeg om een specifieke versietag in productie te gebruiken om onbedoelde upgrade naar een nieuwere versie te voorkomen.

U kunt een volledige lijst met beschikbare tags downloaden.

Tip

Bij de installatie met Helm is het taggen van afbeeldingen geoptimaliseerd voor u. De toepassingsversie van de Helm-grafiek maakt de gateway vast aan een bepaalde versie en is niet afhankelijk latestvan.

Meer informatie over het installeren van een zelf-hostende API Management-gateway in Kubernetes met Helm.

Containerbronnen

Standaard worden in het YAML-bestand dat is opgegeven in Azure Portal geen containerresourceaanvragen opgegeven.

Het is onmogelijk om op betrouwbare wijze de hoeveelheid CPU- en geheugenresources per container te voorspellen en aan te bevelen en het aantal replica's dat nodig is voor het ondersteunen van een specifieke workload. Veel factoren spelen een rol, zoals:

  • Specifieke hardware waarop het cluster wordt uitgevoerd.
  • Aanwezigheid en type virtualisatie.
  • Aantal en snelheid van gelijktijdige clientverbindingen.
  • Aanvraagsnelheid.
  • Soort en aantal geconfigureerde beleidsregels.
  • Grootte van nettolading en of nettoladingen worden gebufferd of gestreamd.
  • Latentie van back-endservice.

We raden u aan resourceaanvragen in te stellen op twee kernen en 2 GiB als uitgangspunt. Voer een belastingstest uit en schaal omhoog of omlaag/omlaag op basis van de resultaten.

Aangepaste domeinnamen en SSL-certificaten

Als u aangepaste domeinnamen gebruikt voor de API Management-eindpunten, met name als u een aangepaste domeinnaam gebruikt voor het beheereindpunt, moet u mogelijk de waarde van config.service.endpoint het <bestand gatewaynaam.yaml> bijwerken om de standaarddomeinnaam te vervangen door de aangepaste domeinnaam. Zorg ervoor dat het beheereindpunt toegankelijk is vanaf de pod van de zelf-hostende gateway in het Kubernetes-cluster.

Als in dit scenario het SSL-certificaat dat wordt gebruikt door het beheereindpunt niet is ondertekend door een bekend CA-certificaat, moet u ervoor zorgen dat het CA-certificaat wordt vertrouwd door de pod van de zelf-hostende gateway.

Notitie

Met de zelf-hostende gateway v2 biedt API Management een nieuw configuratie-eindpunt: <apim-service-name>.configuration.azure-api.net. Aangepaste hostnamen worden ondersteund voor dit eindpunt en kunnen worden gebruikt in plaats van de standaardhostnaam.

DNS-beleid

DNS-naamomzetting speelt een belangrijke rol in de mogelijkheid van een zelf-hostende gateway om verbinding te maken met afhankelijkheden in Azure en API-aanroepen naar back-endservices te verzenden.

Het YAML-bestand dat is opgegeven in Azure Portal, past het standaardbeleid ClusterFirst toe. Dit beleid zorgt ervoor dat aanvragen voor naamomzetting niet worden omgezet door de dns-cluster die wordt doorgestuurd naar de upstream-DNS-server die is overgenomen van het knooppunt.

Zie de Kubernetes-website voor meer informatie over naamomzetting in Kubernetes. Overweeg om het DNS-beleid of de DNS-configuratie aan te passen voor uw installatie.

Beleid voor extern verkeer

Het YAML-bestand dat is opgegeven in De Azure-portal stelt externalTrafficPolicy het veld voor het serviceobject in op Local. Hierdoor blijft het IP-adres van de aanroeper behouden (toegankelijk in de aanvraagcontext) en wordt taakverdeling tussen knooppunten uitgeschakeld, waardoor netwerkhops worden geëlimineerd die hierdoor worden veroorzaakt. Houd er rekening mee dat deze instelling kan leiden tot asymmetrische distributie van verkeer in implementaties met een ongelijk aantal gatewaypods per knooppunt.

Hoge beschikbaarheid

De zelf-hostende gateway is een cruciaal onderdeel in de infrastructuur en moet maximaal beschikbaar zijn. Fouten kunnen echter wel optreden.

Overweeg om de zelf-hostende gateway te beveiligen tegen onderbrekingen.

Tip

Bij de installatie met Helm kunt u eenvoudig hoge beschikbaarheidsplanning inschakelen door de highAvailability.enabled configuratieoptie in te schakelen.

Meer informatie over het installeren van een zelf-hostende API Management-gateway in Kubernetes met Helm.

Beveiliging tegen knooppuntfouten

Als u wilt voorkomen dat dit wordt beïnvloed door storingen in het datacenter of knooppunt, kunt u overwegen een Kubernetes-cluster te gebruiken dat beschikbaarheidszones gebruikt om hoge beschikbaarheid op knooppuntniveau te bereiken.

Met beschikbaarheidszones kunt u de pod van de zelf-hostende gateway plannen op knooppunten verspreid over de zones met behulp van:

Notitie

Als u Azure Kubernetes Service gebruikt, leert u in dit artikel hoe u beschikbaarheidszones gebruikt.

Beveiliging tegen onderbreking van pods

Pods kunnen onderbrekingen ondervinden vanwege verschillende redenen, zoals handmatig verwijderen van pods, knooppuntonderhoud, enzovoort.

Overweeg om podonderbrekingsbudgetten te gebruiken om een minimum aantal pods af te dwingen dat op elk gewenst moment beschikbaar is.

HTTP(S)-proxy

De zelf-hostende gateway biedt ondersteuning voor HTTP(S)-proxy met behulp van de traditionele HTTP_PROXYen HTTPS_PROXYNO_PROXY omgevingsvariabelen.

Zodra deze is geconfigureerd, gebruikt de zelf-hostende gateway automatisch de proxy voor alle uitgaande HTTP(S)-aanvragen voor de back-endservices.

Vanaf versie 2.1.5 of hoger biedt de zelf-hostende gateway waarneembaarheid met betrekking tot het aanvragen van proxy's:

  • API Inspector toont aanvullende stappen wanneer de HTTP(S)-proxy wordt gebruikt en de bijbehorende interacties.
  • Uitgebreide logboeken worden verstrekt om het gedrag van de aanvraagproxy aan te geven.

Notitie

Vanwege een bekend probleem met HTTP-proxy's met behulp van basisverificatie, wordt validatie van certificaatintrekkingslijsten (CRL) niet ondersteund. In onze zelf-hostende gatewayinstellingen vindt u meer informatie over hoe u deze op de juiste manier configureert.

Waarschuwing

Zorg ervoor dat aan de infrastructuurvereisten is voldaan en dat de zelf-hostende gateway nog steeds verbinding kan maken of dat bepaalde functionaliteit niet goed werkt.

Lokale logboeken en metrische gegevens

De zelf-hostende gateway verzendt telemetrie naar Azure Monitor en Azure-toepassing Insights volgens configuratie-instellingen in de bijbehorende API Management-service. Wanneer de verbinding met Azure tijdelijk is verbroken, wordt de stroom van telemetrie naar Azure onderbroken en gaan de gegevens verloren voor de duur van de storing.

Overweeg het gebruik van Azure Monitor Container Insights om uw containers te bewaken of lokale bewaking in te stellen om ervoor te zorgen dat API-verkeer kan worden waargenomen en telemetrieverlies tijdens azure-connectiviteitsstoringen kan worden voorkomen.

Naamruimte

Kubernetes-naamruimten helpen bij het verdelen van één cluster tussen meerdere teams, projecten of toepassingen. Naamruimten bieden een bereik voor resources en namen. Ze kunnen worden gekoppeld aan een resourcequotum en toegangsbeheerbeleid.

Azure Portal biedt opdrachten voor het maken van zelf-hostende gatewaybronnen in de standaardnaamruimte . Deze naamruimte wordt automatisch gemaakt, bestaat in elk cluster en kan niet worden verwijderd. Overweeg om een zelf-hostende gateway te maken en te implementeren in een afzonderlijke naamruimte in productie.

Aantal replica's

Het minimum aantal replica's dat geschikt is voor productie is drie, bij voorkeur gecombineerd met een hoge beschikbaarheid van de exemplaren.

Standaard wordt een zelf-hostende gateway geïmplementeerd met een RollingUpdate-implementatiestrategie. Controleer de standaardwaarden en overweeg expliciet de velden maxUnavailable en maxSurge in te stellen, met name wanneer u een hoog aantal replica's gebruikt.

Prestaties

We raden u aan om containerlogboeken te beperken tot waarschuwingen (warn) om de prestaties te verbeteren. Meer informatie vindt u in onze zelf-hostende gatewayconfiguratieverwijzing.

Aanvraagbeperking

Aanvraagbeperking in een zelf-hostende gateway kan worden ingeschakeld met behulp van het API Management-beleid voor frequentielimiet of frequentielimiet per sleutel. Configureer frequentielimietaantallen om te synchroniseren tussen gateway-exemplaren tussen clusterknooppunten door de volgende poorten in de Kubernetes-implementatie beschikbaar te maken voor exemplaardetectie:

  • Poort 4290 (UDP) voor de snelheidsbeperkingssynchronisatie
  • Poort 4291 (UDP) voor het verzenden van heartbeats naar andere exemplaren

Notitie

Frequentielimietaantallen in een zelf-hostende gateway kunnen worden geconfigureerd om lokaal te synchroniseren (tussen gateway-exemplaren tussen clusterknooppunten), bijvoorbeeld via implementatie van Helm-grafieken voor Kubernetes of met behulp van de Azure Portal-implementatiesjablonen. Frequentielimieten worden echter niet gesynchroniseerd met andere gatewayresources die zijn geconfigureerd in het API Management-exemplaar, inclusief de beheerde gateway in de cloud.

Beveiliging

De zelf-hostende gateway kan worden uitgevoerd als niet-hoofdmap in Kubernetes, zodat klanten de gateway veilig kunnen uitvoeren.

Hier volgt een voorbeeld van de beveiligingscontext voor de zelf-hostende gatewaycontainer:

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

Waarschuwing

Het uitvoeren van de zelf-hostende gateway met het alleen-lezen bestandssysteem (readOnlyRootFilesystem: true) wordt niet ondersteund.

Waarschuwing

Wanneer u lokale CA-certificaten gebruikt, moet de zelf-hostende gateway worden uitgevoerd met gebruikers-id (UID) 1001 om de CA-certificaten te beheren, anders wordt de gateway niet opgestart.

Volgende stappen