Een zelf-hostende gateway implementeren op Kubernetes

Artikel
10/09/2021
6 minuten om te lezen

In dit artikel worden de stappen beschreven voor het implementeren van het zelf-hostende gatewayonderdeel van Azure API Management naar een Kubernetes-cluster.

Notitie

U kunt ook een zelf-hostende gateway implementeren op Azure Arc Kubernetes-cluster als clusterextensie.

Vereisten

Voltooi de volgende snelstartgids: Een Azure API Management-exemplaar maken.
Maak een Kubernetes-cluster.

Tip

Clusters met één knooppunt werken goed voor ontwikkelings- en evaluatiedoeleinden. Kubernetes Certified multi-node clusters on-premises of in de cloud gebruiken voor productieworkloads.
Een zelf-hostende gatewayresource inrichten in uw API Management-exemplaar.

Implementeren naar Kubernetes

Selecteer Gateways onder Implementatie en infrastructuur.
Selecteer de zelf-hostende gatewayresource die u wilt implementeren.
Selecteer Implementatie.
Er is automatisch een toegangs token in het tekstvak Token gegenereerd op basis van de standaardwaarden Vervaldatum en Geheime sleutel. Kies indien nodig waarden in een van beide besturingselementen of beide besturingselementen om een nieuw token te genereren.
Selecteer het tabblad Kubernetes onder Implementatiescripts.
Selecteer de <gateway-name> koppeling .yml-bestand en download het YAML-bestand.
Selecteer het kopieerpictogram in de rechterbenedenhoek van het tekstvak Implementeren om de opdrachten op te slaan kubectl op het klembord.
Plak opdrachten in het terminalvenster (of het opdrachtvenster). Met de eerste opdracht maakt u een Kubernetes-geheim dat het toegangstoken bevat dat in stap 4 is gegenereerd. Met de tweede opdracht wordt het configuratiebestand dat u in stap 6 hebt gedownload, toegepast op het Kubernetes-cluster en wordt verwacht dat het bestand in de huidige map staat.
Voer de opdrachten uit om de benodigde Kubernetes-objecten te maken in de standaardnaamruimte en start zelf-hostende gatewaypods vanuit de containerafbeelding die u hebt gedownload van de Microsoft Container Registry.
Voer de volgende opdracht uit om te controleren of de implementatie is geslaagd. Houd er rekening mee dat het even kan duren voor alle objecten zijn gemaakt en dat de pods worden initialiseren.
```
kubectl get deployments
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
<gateway-name>   1/1     1            1           18s
```

Voer de volgende opdracht uit om te controleren of de service is gemaakt. Houd er rekening mee dat uw service-IP's en poorten anders zijn.

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

Terug naar de Azure Portal en selecteer Overzicht.
Controleer of status een groen vinkje bevat, gevolgd door een aantal knooppunt dat overeenkomt met het aantal replica's dat is opgegeven in het YAML-bestand. Deze status betekent dat de geïmplementeerde zelf-hostende gatewaypods met de API Management-service communiceren en een normale heartbeat hebben.

Tip

Voer de opdracht uit om logboeken van een willekeurig geselecteerde pod weer te geven als kubectl logs deployment/<gateway-name> er meer dan één pod is. Voer uit voor een volledige set opdrachtopties, zoals het weergeven van logboeken kubectl logs -h voor een specifieke pod of container.

Overwegingen voor productie-implementatie

Toegangs token

Zonder een geldig toegangsken kan een zelf-hostende gateway geen toegang krijgen tot configuratiegegevens en deze niet downloaden vanaf het eindpunt van de gekoppelde API Management service. Het toegangsteken kan maximaal 30 dagen geldig zijn. Het moet opnieuw worden ge regenereerd en het cluster moet worden geconfigureerd met een nieuw token, handmatig of via automatisering voordat het verloopt.

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

Naamruimte

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

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

Aantal replica's

Het minimale aantal replica's dat geschikt is voor productie is twee.

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

Containerresources

Het YAML-bestand dat is opgegeven in de Azure Portal bevat standaard geen containerresourceaanvragen.

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 is vereist voor de ondersteuning van een specifieke workload. Er spelen veel factoren een rol, zoals:

Specifieke hardware op het cluster wordt uitgevoerd.
Aanwezigheid en type virtualisatie.
Aantal en snelheid van gelijktijdige clientverbindingen.
Aanvraagsnelheid.
Soort en aantal geconfigureerde beleidsregels.
Nettoladinggrootte en of nettoladingen worden gebufferd of gestreamd.
Latentie van back-en-service.

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

Tag voor containerafbeelding

Het YAML-bestand in de Azure Portal maakt gebruik van de nieuwste tag. Deze tag verwijst altijd naar de meest recente versie van de zelf-hostende gatewaycontainer-afbeelding.

Overweeg het gebruik van een specifieke versietag in productie om onbedoelde upgrade naar een nieuwere versie te voorkomen.

U kunt een volledige lijst met beschikbare tags downloaden.

DNS-beleid

DNS-naamresolutie speelt een cruciale 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 het standaardbeleid ClusterFirst. Dit beleid zorgt ervoor dat naamoplossingsaanvragen die niet worden opgelost door de CLUSTER-DNS, worden doorgestuurd naar de upstream-DNS-server die is overgenomen van het knooppunt.

Zie de Kubernetes-websitevoor meer informatie over naamresolutie in Kubernetes. Overweeg om het DNS-beleid of de DNS-configuratie aan te passen die geschikt is voor uw installatie.

Beleid voor extern verkeer

Het YAML-bestand dat is opgegeven in Azure Portal externalTrafficPolicy veld sets op het serviceobject op Local . Hiermee behoudt u het IP-adres van de aanroeper (toegankelijk in de context van de aanvraag)en wordt taakverdeling tussen knooppunts uitschakeling, waardoor netwerkhops die hierdoor worden veroorzaakt, worden verwijderd. Let op: deze instelling kan leiden tot asymmetrische distributie van verkeer in implementaties met een ongelijk aantal gatewaypods per knooppunt.

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 beheer-eindpunt, moet u mogelijk de waarde van bijwerken in het config.service.endpoint <gateway-name> YAML-bestand om de standaarddomeinnaam te vervangen door de aangepaste domeinnaam. Zorg ervoor dat het beheer-eindpunt toegankelijk is vanuit de pod van de zelf-hostende gateway in het Kubernetes-cluster.

Als in dit scenario het SSL-certificaat dat wordt gebruikt door het beheer-eindpunt 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.

Configuratieback-up

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

Configureer een lokaal opslagvolume voor de zelf-hostende gatewaycontainer, zodat er een back-up van de meest recente gedownloade configuratie kan worden opgeslagen. Als de verbinding niet is verbonden, kan het opslagvolume de back-upkopie gebruiken bij het opnieuw opstarten. Het pad voor volume-mount moet /apim/config zijn. Zie een voorbeeld op GitHub. Zie de Kubernetes-website voor meer informatie over opslag in Kubernetes.

Lokale logboeken en metrische gegevens

De zelf-hostende gateway verzendt telemetriegegevens naar Azure Monitor en Azure-toepassing Insights volgens de configuratie-instellingen in de gekoppelde API Management service. Wanneer de verbinding met Azure tijdelijk verloren gaat, wordt de stroom van telemetrie naar Azure onderbroken en gaan de gegevens verloren voor de duur van de storing. Overweeg lokale bewaking in te stellen om ervoor te zorgen dat u API-verkeer kunt observeren en telemetrieverlies kunt voorkomen tijdens uitval van Azure-connectiviteit.

Volgende stappen

Zie Overzicht van zelf-hostende gateway voor meer informatie over de zelf-hostende gateway.
Meer informatie over het implementeren API Management zelf-hostende gateway naar Azure Arc Kubernetes-clusters met ingeschakelde .