Verwenden von API Management mit in Azure Kubernetes Service bereitgestellten Microservices

GILT FÜR: Alle API Management-Ebenen

Microservices eignen sich optimal für die Erstellung von APIs. Sie können Azure Kubernetes Service (AKS) verwenden, um schnell eine mikroservicesbasierte Architektur in der Cloud bereitzustellen und zu betreiben. Anschließend können Sie Azure API Management verwenden, um Ihre Microservices als APIs für den internen und externen Verbrauch zu veröffentlichen. In diesem Artikel werden die Optionen für die Verwendung der API-Verwaltung zum Veröffentlichen von AKS-Mikroservices-basierten Architekturen als APIs beschrieben. Dabei wird davon ausgegangen, dass Kubernetes, API-Verwaltung und Azure-Netzwerke grundkenntnisse sind.

Hintergrund

Wenn Sie Microservices als APIs für den Verbrauch veröffentlichen, kann es schwierig sein, die Kommunikation zwischen den Microservices und den Clients zu verwalten, die sie nutzen. Zu den übergreifenden Bedenken gehören Authentifizierung, Autorisierung, Drosselung, Zwischenspeicherung, Transformation und Überwachung. Diese Bedenken gelten unabhängig davon, ob die Microservices internen oder externen Clients ausgesetzt sind.

Das API-Gateway-Muster hilft dabei, diese Aspekte zu berücksichtigen und einzubeziehen. Ein API-Gateway fungiert als Eingangstür zu den Microservices, entkoppelt Clients von Ihren Microservices, fügt eine weitere Sicherheitsebene hinzu und reduziert die Komplexität Ihrer Microservices, indem es die Last der Behandlung von bereichsübergreifenden Anliegen entfernt.

Die API-Verwaltung ist eine schlüsselfertige Lösung, um Ihre API-Gatewayanforderungen zu lösen. Sie können schnell ein konsistentes und modernes Gateway für Ihre Microservices erstellen und sie als APIs veröffentlichen. Als Vollständige API-Verwaltungslösung bietet sie auch zusätzliche Funktionen, einschließlich eines Self-Service-Entwicklerportals für API-Ermittlung, API-Lebenszyklusverwaltung und API-Analysen.

In Kombination bieten AKS und API Management eine Plattform für die Bereitstellung, Veröffentlichung, Sicherung, Überwachung und Verwaltung Ihrer auf Microservices basierenden APIs. In diesem Artikel werden einige Optionen für die Bereitstellung von AKS in Verbindung mit der API-Verwaltung beschrieben.

Kubernetes Services und APIs

In einem Kubernetes-Cluster werden Container in Pods bereitgestellt. Diese sind kurzlebig und haben einen Lebenszyklus. Wenn ein Workerknoten ausfällt, gehen die auf dem Knoten ausgeführten Pods verloren. Daher kann sich die IP-Adresse eines Pods jederzeit ändern. Sie können sich nicht darauf verlassen, mit dem Pod zu kommunizieren.

Um dieses Problem zu lösen, wurde mit Kubernetes das Konzept der Dienste eingeführt. Ein Kubernetes-Dienst ist eine Abstraktionsebene, die eine logische Gruppe von Pods definiert und externe Datenverkehrsexposition, Lastenausgleich und Dienstermittlung für diese Pods ermöglicht.

Wenn Sie bereit sind, Ihre Microservices mithilfe der API-Verwaltung als APIs zu veröffentlichen, müssen Sie überlegen, wie Sie Ihre Dienste in Kubernetes APIs in DER API-Verwaltung zuordnen. Für diese Zuordnung wurden keine Regeln festgelegt. Es hängt davon ab, wie Sie Ihre Geschäftsfunktionen und -domänen am Anfang entworfen und in Microservices partitioniert haben. Wenn beispielsweise die Pods hinter einem Dienst für alle Vorgänge einer bestimmten Ressource (z. B. "Kunde") verantwortlich sind, können Sie den Dienst einer API zuordnen. Wenn Vorgänge für eine Ressource in mehrere Microservices (z. B. GetOrder und PlaceOrder) partitioniert werden, können Sie mehrere Dienste in einer einzelnen API in der API-Verwaltung aggregieren. (Siehe das folgende Diagramm.)

Die Zuordnungen können auch weiterentwickelt werden. Da die API-Verwaltung vor den Microservices eine Fassade erstellt, können Sie Ihre Microservices im Laufe der Zeit umgestalten und ihre Größe richtig anpassen.

Bereitstellen von API Management vor AKS

Es gibt einige Optionen für die Bereitstellung der API-Verwaltung vor einem AKS-Cluster.

Ein AKS-Cluster wird immer in einem virtuellen Netzwerk bereitgestellt, aber eine API-Verwaltungsinstanz wird nicht unbedingt in einem virtuellen Netzwerk bereitgestellt. Wenn sich die API-Verwaltung nicht im virtuellen Clusternetzwerk befindet, muss der AKS-Cluster öffentliche Endpunkte für die API-Verwaltung veröffentlichen, mit der eine Verbindung hergestellt werden kann. In diesem Fall müssen Sie die Verbindung zwischen API-Verwaltung und AKS sichern. Mit anderen Worten: Sie müssen sicherstellen, dass nur über die API-Verwaltung auf den Cluster zugegriffen werden kann. In den folgenden Abschnitten werden die Optionen für die Bereitstellung der API-Verwaltung vor AKS beschrieben.

Option 1: Öffentlich Verfügbarmachen von Diensten

Sie können Dienste in einem AKS-Cluster öffentlich verfügbar machen, indem Sie die Typen NodePort, LoadBalancer oder ExternalName Service verwenden. Wenn Sie dies tun, sind Dienste direkt über das öffentliche Internet zugänglich. Nach der Bereitstellung der API-Verwaltung vor dem Cluster müssen Sie sicherstellen, dass der gesamte eingehende Datenverkehr die API-Verwaltung durchläuft, indem Sie die Authentifizierung in den Microservices anwenden. Beispielsweise kann API Management ein Zugriffstoken in jede Anforderung an den Cluster einbinden. Jeder Microservice muss das Token überprüfen, bevor die Anforderung verarbeitet wird.

Diese Option bietet möglicherweise die einfachste Möglichkeit, die API-Verwaltung vor AKS bereitzustellen, insbesondere, wenn Sie bereits Authentifizierungslogik in Ihren Microservices implementiert haben.

Vorteile:

• Einfache Konfiguration auf der API-Verwaltungsseite, da die API-Verwaltung nicht in das virtuelle Clusternetzwerk eingefügt werden muss
• Keine Änderung auf der AKS-Seite, wenn Sie die Dienste bereits öffentlich verfügbar gemacht haben und die Microservices bereits eine Authentifizierungslogik enthalten

Nachteile:

• Schafft potenzielles Sicherheitsrisiko aufgrund der öffentlichen Sichtbarkeit von Endpunkten
• Erstellt keinen einzelnen Einstiegspunkt für eingehenden Cluster-Verkehr.
• Kompliliert Microservices mit doppelter Authentifizierungslogik

Option 2: Installieren eines Eingangscontrollers

Obwohl Option 1 möglicherweise einfacher ist, hat sie wichtige Nachteile, wie bereits erwähnt. Wenn sich eine API-Verwaltungsinstanz nicht im virtuellen Clusternetzwerk befindet, ist die gegenseitige TLS-Authentifizierung (mTLS) eine robuste Möglichkeit, sicherzustellen, dass der Datenverkehr in beide Richtungen zwischen einer API-Verwaltungsinstanz und einem AKS-Cluster sicher und vertrauenswürdig ist.

Die gegenseitige TLS-Authentifizierung wird von der API-Verwaltung nativ unterstützt . Sie können es in Kubernetes aktivieren, indem Sie einen Eingangscontroller installieren. (Siehe das folgende Diagramm.) Daher erfolgt die Authentifizierung im Eingangscontroller, wodurch die Microservices vereinfacht werden. Darüber hinaus können Sie in Dienstebenen, die dedizierte IP-Adressen unterstützen, die IP-Adressen der API-Verwaltung zur Zulassungsliste hinzufügen, um sicherzustellen, dass nur die API-Verwaltung Zugriff auf den Cluster hat.

Vorteile:

• Ermöglicht eine einfache Konfiguration auf der API-Verwaltungsseite, da die API-Verwaltung nicht in das virtuelle Clusternetzwerk eingefügt werden muss und mTLS nativ unterstützt wird.
• Zentralisiert den Schutz für eingehenden Clusterdatenverkehr auf der Ebene des Eingangsdatencontrollers
• Verringert das Sicherheitsrisiko, indem die Anzahl öffentlich sichtbarer Clusterendpunkte minimiert wird

Nachteile:

• Erhöht die Komplexität der Clusterkonfiguration, da Sie den Eingangscontroller installieren, konfigurieren und verwalten und Zertifikate verwalten müssen, die für mTLS verwendet werden
• Fügt Sicherheitsrisiken aufgrund der öffentlichen Sichtbarkeit von Endpunkten des Ingresscontrollers hinzu, es sei denn, Sie verwenden API Management Standard v2 oder Premium-Ebene.

Wenn Sie APIs über die API-Verwaltung veröffentlichen, ist es einfach und typisch, den Zugriff auf diese APIs mithilfe von Abonnementschlüsseln zu sichern. Entwickler, die die veröffentlichten APIs nutzen möchten, müssen einen gültigen Abonnementschlüssel in HTTP-Anforderungen einschließen, wenn sie Aufrufe an diese APIs senden. Andernfalls werden die Aufrufe sofort vom API Management-Gateway abgelehnt. Sie werden nicht an die Back-End-Dienste weitergeleitet.

Um einen Abonnementschlüssel für den Zugriff auf APIs zu erhalten, benötigen Entwickler ein Abonnement. Ein Abonnement ist im Wesentlichen ein benannter Container für ein Paar von Abonnementschlüsseln. Entwickler, die die veröffentlichten APIs verarbeiten müssen, können Abonnements erhalten. Sie benötigen keine Genehmigung von API-Herausgebern. API-Herausgeber können Abonnements für API-Nutzer auch direkt erstellen.

Option 3: Bereitstellen der API-Verwaltung im virtuellen Clusternetzwerk

In einigen Fällen können Kunden, die gesetzliche Einschränkungen oder strenge Sicherheitsanforderungen haben, Optionen 1 und 2 aufgrund der öffentlich zugänglichen Endpunkte als nicht machbar empfinden. In anderen Befinden sich der AKS-Cluster und die Anwendungen, die die Microservices nutzen, möglicherweise innerhalb desselben virtuellen Netzwerks, daher gibt es keinen Grund, den Cluster öffentlich verfügbar zu machen, da der gesamte API-Datenverkehr innerhalb des virtuellen Netzwerks verbleibt. In diesen Szenarien können Sie die API-Verwaltung im virtuellen Clusternetzwerk bereitstellen. API Management Developer, Premium und Premium v2 (Vorschau) unterstützen die Einfügung in das virtuelle Clusternetzwerk.

Es gibt zwei Modi zum Bereitstellen der API-Verwaltung in einem virtuellen Netzwerk: extern und intern. Derzeit ist der externe Modus nur in den klassischen Ebenen der API-Verwaltung verfügbar.

Wenn sich API-Verbraucher nicht im virtuellen Clusternetzwerk befinden, sollten Sie den externen Modus verwenden. (Siehe das folgende Diagramm.) In diesem Modus wird das API-Verwaltungsgateway in das virtuelle Clusternetzwerk integriert, aber über einen externen Load Balancer über das öffentliche Internet zugänglich. Diese Architektur hilft dabei, den Cluster vollständig auszublenden und gleichzeitig externen Clients die Nutzung der Microservices zu ermöglichen. Darüber hinaus können Sie Azure-Netzwerkfunktionen wie Netzwerksicherheitsgruppen (Network Security Groups, NSG) verwenden, um den Netzwerkdatenverkehr einzuschränken.

Wenn sich alle API-Consumer im virtuellen Clusternetzwerk befinden, können Sie den internen Modus verwenden. (Siehe das folgende Diagramm.) In diesem Modus wird das API-Verwaltungsgateway in das virtuelle Clusternetzwerk eingefügt und kann nur über einen internen Lastenausgleich über dieses virtuelle Netzwerk zugänglich sein. Es gibt keine Möglichkeit, das API-Verwaltungsgateway oder den AKS-Cluster aus dem öffentlichen Internet zu erreichen.

Der AKS-Cluster ist in beiden Fällen nicht öffentlich sichtbar. Im Gegensatz zu Option 2 ist der Eingangscontroller möglicherweise nicht erforderlich. Je nach Ihrem Szenario und Ihrer Konfiguration ist möglicherweise noch eine Authentifizierung zwischen API Management und Ihren Microservices erforderlich. Wenn Sie beispielsweise ein Dienstgitter verwenden, benötigen Sie immer eine gegenseitige TLS-Authentifizierung.

Vorteile:

• Stellt die sicherste Option bereit, da der AKS-Cluster keinen öffentlichen Endpunkt hat.
• Vereinfacht die Clusterkonfiguration, da kein öffentlicher Endpunkt vorhanden ist.
• Bietet die Möglichkeit, sowohl die API-Verwaltung als auch AKS im virtuellen Netzwerk mithilfe des internen Modus auszublenden
• Bietet die Möglichkeit, den Netzwerkdatenverkehr mithilfe von Azure-Netzwerkfunktionen wie NSG zu steuern

Nachteile:

• Erhöht die Komplexität der Bereitstellung und Konfiguration der API-Verwaltung für die Arbeit im virtuellen Netzwerk

Verwandte Inhalte

• Netzwerkkonzepte für Anwendungen in AKS
• Verwenden der API-Verwaltung mit virtuellen Netzwerken