Anleitung zum Ausführen eines selbstgehosteten Gateways in Kubernetes in der Produktion

  • Artikel

GILT FÜR: Entwickler | Premium

Um das selbstgehostete Gateway in der Produktion ausführen zu können, müssen verschiedene Aspekte berücksichtigt werden. Beispielsweise sollte das Gateway auf hochverfügbare Weise bereitgestellt werden und Konfigurationssicherungen verwenden, um temporäre Verbindungsunterbrechungen verarbeiten zu können.

Dieser Artikel enthält eine Anleitung zum Ausführen selbstgehosteter Gateways in Kubernetes für Produktionsworkloads, um sicherzustellen, dass diese reibungslos und zuverlässig ausgeführt werden.

Zugriffstoken

Ohne ein gültiges Zugriffstoken kann ein selbstgehostetes Gateway nicht am Endpunkt des zugeordneten API Management-Diensts auf Konfigurationsdaten zugreifen und diese herunterzuladen. Das Zugriffstoken ist maximal 30 Tage gültig. Es muss neu generiert und der Cluster entweder manuell oder mittels Automatisierung mit einem neuen Token konfiguriert werden, bevor es abläuft.

Wenn Sie die Tokenaktualisierung automatisieren, generieren Sie über diesen Vorgang der Verwaltungs-API ein neues Token. Informationen zur Verwaltung von Kubernetes-Geheimnissen finden Sie auf der Kubernetes-Website.

Tipp

Sie können das selbstgehostete Gateway auch in Kubernetes bereitstellen und die Authentifizierung bei der API Management-Instanz mithilfe von Azure AD aktivieren.

Automatische Skalierung

Wir bieten zwar Anleitungen zur Mindestanzahl von Replikaten für das selbstgehostete Gateway, es wird jedoch empfohlen, die automatische Skalierung für das selbstgehostete Gateway zu verwenden, um den Bedarf Ihres Datenverkehrs proaktiver zu erfüllen.

Es gibt zwei Möglichkeiten, das selbstgehostete Gateway horizontal automatisch zu skalieren:

  • Automatische Skalierung basierend auf der Ressourcenauslastung (CPU und Arbeitsspeicher)
  • Automatische Skalierung basierend auf der Anzahl von Anforderungen pro Sekunde

Dies kann über native Kubernetes-Funktionalitäten erfolgen oder durch Verwendung der ereignisgesteuerten automatischen Skalierung von Kubernetes (Kubernetes Event-Driven Autoscaling, KEDA). KEDA ist ein CSVF-Inkubationsprojekt, mit dem die automatische Skalierung von Anwendungen vereinfacht werden soll.

Hinweis

KEDA ist eine Open-Source-Technologie, die nicht vom Azure-Support unterstützt wird und von den Kunden betrieben werden muss.

Ressourcenbasierte automatische Skalierung

Mit Kubernetes können Sie das selbstgehostete Gateway basierend auf der Ressourcenauslastung mithilfe einer horizontalen automatischen Podskalierung automatisch skalieren. Dies erlaubt es Ihnen, CPU- und Arbeitsspeicherschwellenwerte zu definieren sowie die Anzahl der Replikate als Ziel einer angestrebten Auf- oder Abskalierung.

Eine Alternative ist die Verwendung der ereignisgesteuerten automatischen Skalierung von Kubernetes (Kubernetes Event-Driven Autoscaling, KEDA), mit der Sie Workloads basierend auf einer Vielzahl von Skalierungsfaktoren skalieren können, einschließlich CPU und Arbeitsspeicher.

Tipp

Wenn Sie KEDA bereits zum Skalieren anderer Workloads verwenden, wird empfohlen, KEDA als einheitliche automatische App-Skalierung zu verwenden. Wenn dies nicht der Fall ist, wird dringend empfohlen, die native Kubernetes-Funktionalität über die automatische horizontale Podskalierung zu verwenden.

Datenverkehrsbasierte automatische Skalierung

Kubernetes bietet keinen vorgefertigten Mechanismus für die datenverkehrsbasierte automatische Skalierung.

KEDA (Kubernetes Event-Driven Autoscaling) bietet einige Möglichkeiten, die bei der datenverkehrsbasierten automatischen Skalierung hilfreich sein können:

  • Sie können basierend auf Metriken aus einer eingehenden Kubernetes-Erfassung skalieren, wenn sie in Prometheus oder Azure Monitor verfügbar sind, indem Sie eine sofort einsatzbereite Skalierung verwenden.
  • Sie können das HTTP-Add-On installieren, das in der Betaversion verfügbar ist und basierend auf der Anzahl der Anforderungen pro Sekunde eine Skalierung vornimmt.

Sicherung der Konfiguration

Konfigurieren Sie ein lokales Speichervolume für den selbstgehosteten Gatewaycontainer, damit dieser eine Sicherungskopie der zuletzt heruntergeladenen Konfiguration speichert. Bei Ausfall der Verbindung kann das Speichervolume die Sicherungskopie nach einem Neustart verwenden. Der Volumeeinbindungspfad muss /apim/config lauten und im Besitz der Gruppen-ID 1001 sein. Ein Beispiel finden Sie auf GitHub. Informationen zu Speicher in Kubernetes finden Sie auf der Kubernetes-Website. Informationen zum Ändern des Besitzes für einen eingebundenen Pfad finden Sie unter der Einstellung securityContext.fsGroup auf der Kubernetes-Website.

Hinweis

Weitere Informationen zum Verhalten selbstgehosteter Gateways bei einem vorübergehenden Ausfall der Verbindung mit Azure finden Sie unter Selbstgehostetes Gateway – Übersicht.

Tag für Containerimage

Die im Azure-Portal bereitgestellte YAML-Datei verwendet das Tag latest. Dieses Tag verweist stets auf die neueste Version des Containerimages des selbstgehosteten Gateways.

Erwägen Sie die Verwendung eines speziellen Versionstags in der Produktion, um eine unbeabsichtigte Aktualisierung auf eine neuere Version zu vermeiden.

Sie können eine vollständige Liste der verfügbaren Tags herunterladen.

Tipp

Bei der Installation mit Helm ist das Imagetagging für Sie optimiert. Die Anwendungsversion des Helm-Charts heftet das Gateway an eine bestimmte Version an und ist nicht auf latest angewiesen.

Weitere Informationen finden Sie unter Installieren selbstgehosteter API Management-Gateways in Kubernetes mit Helm.

Containerressourcen

Standardmäßig gibt die im Azure-Portal bereitgestellte YAML-Datei keine Anforderungen von Containerressourcen an.

Es ist unmöglich, die Menge an CPU- und Arbeitsspeicherressourcen pro Container und die Anzahl der Replikate, die zur Unterstützung einer bestimmten Workload erforderlich sind, zuverlässig vorherzusagen und zu empfehlen. Viele Faktoren spielen eine Rolle, z. B.:

  • Spezifische Hardware, auf der der Cluster ausgeführt wird
  • Vorhandensein und Typ der Virtualisierung
  • Anzahl und Rate gleichzeitiger Clientverbindungen
  • Anforderungsrate
  • Art und Anzahl der konfigurierten Richtlinien
  • Nutzlastgröße und ob Nutzlasten gepuffert oder gestreamt werden
  • Wartezeit des Back-End-Diensts

Wir empfehlen, Ressourcenanforderungen auf zwei Kerne und 2 GiB als Ausgangspunkt festzulegen. Führen Sie einen Auslastungstest durch, und skalieren Sie basierend auf den Ergebnissen hoch/auf bzw. herunter/ab.

Benutzerdefinierte Domänennamen und SSL-Zertifikate

Wenn Sie benutzerdefinierte Domänennamen für die API Management-Endpunkteverwenden, vor allem bei einem benutzerdefinierten Domänennamen für den Verwaltungsendpunkt, müssen Sie unter Umständen den Wert von config.service.endpoint in der Datei <gateway-name>.yaml aktualisieren, um den Standarddomänennamen durch den benutzerdefinierten Domänennamen zu ersetzen. Vergewissern Sie sich, dass auf den Verwaltungsendpunkt über den Pod des selbstgehosteten Gateways im Kubernetes-Cluster zugegriffen werden kann.

Wenn das vom Verwaltungsendpunkt verwaltete SSL-Zertifikat nicht von einem bekannten Zertifizierungsstellenzertifikat signiert ist, müssen Sie in diesem Szenario sicherstellen, dass das Zertifizierungsstellenzertifikat vom Pod des selbstgehosteten Gateways als vertrauenswürdig eingestuft wird.

Hinweis

Mit dem selbst gehosteten Gateway v2 bietet API Management einen neuen Konfigurationsendpunkt. <apim-service-name>.configuration.azure-api.net Benutzerdefinierte Hostnamen werden für diesen Endpunkt unterstützt und können anstelle des Standardhosts verwendet werden.

DNS-Richtlinie

Die DNS-Namensauflösung spielt eine entscheidende Rolle bei der Fähigkeit des selbstgehosteten Gateways, eine Verbindung mit Abhängigkeiten in Azure herzustellen und API-Aufrufe an Back-End-Dienste zu senden.

Die im Azure-Portal bereitgestellte YAML-Datei wendet die Standardrichtlinie ClusterFirst an. Diese Richtlinie bewirkt, dass vom Cluster-DNS nicht aufgelöste Namensauflösungsanforderungen an den vom Knoten geerbten vorgelagerten DNS-Server weitergeleitet werden.

Weitere Informationen zur Namensauflösung in Kubernetes finden Sie auf der Kubernetes-Website. Erwägen Sie, die DNS-Richtlinie oder DNS-Konfiguration entsprechend Ihrer Einrichtung anzupassen.

Richtlinie für externen Datenverkehr

Die im Azure-Portal bereitgestellte YAML-Datei legt das Feld externalTrafficPolicy des externalTrafficPolicy-Objekts auf Local fest. Hierdurch bleibt die IP-Adresse des Aufrufers erhalten (Zugriffsmöglichkeit darauf im Anforderungskontext), und der knotenübergreifende Lastenausgleich wird deaktiviert, sodass dadurch verursachte Netzwerkhops beseitigt werden. Beachten Sie, dass diese Einstellung eine asymmetrische Verteilung des Datenverkehrs in Bereitstellungen mit ungleicher Anzahl von Gatewaypods pro Knoten verursachen kann.

Hochverfügbarkeit

Das selbstgehostete Gateway ist eine wichtige Komponente in der Infrastruktur und muss hochverfügbar sein. Es kann jedoch auch zu Fehlern kommen.

Erwägen Sie, das selbstgehostete Gateway vor Unterbrechungen zu schützen.

Tipp

Bei der Installation mit Helm können Sie problemlos eine hochverfügbare Planung aktivieren, indem Sie die Konfigurationsoption highAvailability.enabled aktivieren.

Weitere Informationen finden Sie unter Installieren selbstgehosteter API Management-Gateways in Kubernetes mit Helm.

Schutz vor Knotenausfällen

Erwägen Sie die Verwendung eines Kubernetes-Clusters, der Verfügbarkeitszonen für die Hochverfügbarkeit auf Knotenebene nutzt, um zu verhindern, dass Sie durch Rechenzentrums- oder Knotenausfälle eingeschränkt werden.

Mit Verfügbarkeitszonen können Sie den Pod des selbstgehosteten Gateways auf Knoten in mehreren Zonen zu planen. Verwenden Sie hierzu Folgendes:

Hinweis

Wenn Sie Azure Kubernetes Service verwenden, erfahren Sie in diesem Artikel mehr über die Verwendung von Verfügbarkeitszonen.

Schutz vor Podunterbrechungen

Pods können aus verschiedenen Gründen ausfallen (z. B.manuelles Löschen von Pods, Knotenwartung usw.).

Erwägen Sie die Verwendung von Budgets für die Unterbrechung von Pods, um zu erzwingen, dass eine Mindestanzahl von Pods jederzeit verfügbar ist.

HTTP(S)-Proxy

Das selbstgehostete Gateway unterstützt den HTTP(S)-Proxy mithilfe der herkömmlichen Umgebungsvariablen HTTP_PROXY, HTTPS_PROXY und NO_PROXY.

Nach der Konfiguration verwendet das selbstgehostete Gateway automatisch den Proxy für alle ausgehenden HTTP(S)-Anforderungen an die Back-End-Dienste.

Ab Version 2.1.5 oder höher stellt das selbstgehostete Gateway Einblicke in die Anforderungsweiterleitung bereit:

  • Der API-Inspektor zeigt zusätzliche Schritte, wenn der HTTP(S)-Proxy verwendet wird, und seine verwandten Interaktionen.
  • Ausführliche Protokolle werden bereitgestellt, um Hinweis auf das Verhalten des Anforderungsproxys zu liefern.

Hinweis

Aufgrund eines bekannten Problems mit HTTP-Proxys, die die Basisauthentifizierung verwenden, wird die Validierung von Zertifikatssperrlisten (CRL) nicht unterstützt. Erfahren Sie mehr in unserem Einstellungen für selbst gehostete Gateways, wie Sie diese entsprechend konfigurieren.

Warnung

Stellen Sie sicher, dass die Infrastrukturanforderungen erfüllt wurden und dass das selbstgehostete Gateway weiterhin eine Verbindung mit ihnen herstellen kann, da sonst bestimmte Funktionen nicht mehr ordnungsgemäß funktionieren.

Lokale Protokolle und Metriken

Das selbstgehostete Gateway sendet Telemetriedaten an Azure Monitor und Azure Application Insights gemäß den Konfigurationseinstellungen im zugehörigen API Management-Dienst. Wenn die Verbindung mit Azure vorübergehend unterbrochen wird, wird der Fluss der Telemetriedaten in Azure unterbrochen, sodass die Daten für die Dauer des Ausfalls verloren gehen.

Erwägen Sie die Verwendung von Azure Monitor Container Insights, um Ihre Container zu überwachen, oder die Einrichtung der lokale Überwachung, um sicherzustellen, dass der API-Datenverkehr beobachtet und Telemetriedatenverluste bei Azure-Konnektivitätsausfällen verhindert werden können.

Namespace

Kubernetes-Namespaces helfen bei der Aufteilung eines einzelnen Clusters unter mehreren Teams, Projekten oder Anwendungen. Namespaces stellen einen Bereich für Ressourcen und Namen bereit. Sie können einem Ressourcenkontingent und Zugriffssteuerungsrichtlinien zugeordnet werden.

Der Azure-Portal bietet Befehle zum Erstellen von selbstgehosteten Gatewayressourcen im Standard-Namespace. Dieser Namespace wird automatisch erstellt, ist in jedem Cluster vorhanden und kann nicht gelöscht werden. Erwägen Sie dasErstellen und Bereitstellen eines selbstgehosteten Gateways in einem separaten Namespace in der Produktion.

Anzahl von Replikaten

Für die Produktion sollten mindestens drei Replikate verwendet werden – vorzugsweise in Kombination mit einer hochverfügbaren Planung der Instanzen.

Standardmäßig wird ein selbstgehostetes Gateway mithilfe einer Bereitstellungsstrategie des Typs RollingUpdate bereitgestellt. Überprüfen Sie die Standardwerte, und erwägen Sie das explizite Festlegen der Felder maxUnavailable und maxSurge, insbesondere bei Verwendung einer hohen Anzahl von Replikaten.

Leistung

Es wird empfohlen, Containerprotokolle auf Warnungen (warn) zu reduzieren, um die Leistung zu verbessern. Weitere Informationen finden Sie in unserer Referenz zur Konfiguration des selbstgehosteten Gateways.

Anforderungsdrosselung

Die Anforderungsdrosselung in einem selbstgehosteten Gateway kann mithilfe der API Management-Richtlinie rate-limit oder rate-limit-by-key aktiviert werden. Konfigurieren Sie die Anzahl der Ratengrenzwerte für die Synchronisierung zwischen Gateway-Instanzen über Clusterknoten hinweg, indem Sie die folgenden Ports in der Kubernetes-Bereitstellung für die Instanzermittlung verfügbar machen:

  • Port 4290 (UDP), für die Synchronisierung der Ratengrenzwerte
  • Port 4291 (UDP), zum Senden von Heartbeats an andere Instanzen

Hinweis

Ratengrenzwerte in einem selbstgehosteten Gateway können so konfiguriert werden, dass sie lokal (zwischen Gateway-Instanzen über Clusterknoten hinweg) synchronisiert werden, z. B. über die Helm-Diagrammbereitstellung für Kubernetes oder mithilfe der Bereitstellungsvorlagen des Azure-Portals. Ratengrenzwerte werden jedoch nicht mit anderen in der API Management-Instanz konfigurierten Gateway-Ressourcen synchronisiert, einschließlich des verwalteten Gateways in der Cloud.

Sicherheit

Das selbstgehostete Gateway kann in Kubernetes als Nicht-Root ausgeführt zu werden, sodass Kunden das Gateway sicher ausführen können.

Hier sehen Sie einen exemplarischen Sicherheitskontext für den selbstgehosteten 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

Warnung

Die Ausführung des selbstgehosteten Gateways mit schreibgeschütztem Dateisystem (readOnlyRootFilesystem: true) wird nicht unterstützt.

Warnung

Wenn Sie lokale ZS-Zertifikate verwenden, muss das selbst gehostete Gateway mit Benutzer-ID (UID) 1001 ausgeführt werden, um die ZS-Zertifikate zu verwalten, andernfalls wird das Gateway nicht gestartet.

Nächste Schritte