Nach Istio und darüber hinaus: Azure Service Mesh Interface

Die moderne Cloud-First-Anwendungsentwicklung, zumindest auf Azure, ist fast abhängig von Kubernetes. Technologien wie Virtual Kubelets, AKS (Azure Kubernetes Service) und Azure Service Fabric Mesh sind der Schlüssel zum Erstellen skalierbarer verteilter Anwendungen in Azure, bei denen Container zum Bereitstellen und Verwalten von Microservices verwendet werden.

Bei Betrachtung der Kubernetes-Tools von Azure wird deutlich, dass Microsoft in und um die Cloud Native Computing Foundation viel Arbeit leistet und an allen Aspekten des Open Source-Frameworks arbeitet. Wir sollten nicht überrascht sein; Microsoft stellte einen der Gründer des Kubernetes-Projekts ein und erwarb dann Deis, einen bedeutenden Anbieter. Das Deis-Team steht hinter einem der neuesten Azure-Beiträge zum Kubernetes-Ökosystem, dem Service Mesh Interface (SMI).

Einführung von Service-Meshes

Am besten erklären Sie zunächst, was ein Service-Mesh ist und warum es für jede Kubernetes-basierte Anwendung wichtig ist.

In modernen IT-Architekturen dreht sich alles um Abstraktion. Mit Cloud-Diensten müssen wir nicht mehr an die zugrunde liegende Hardware denken. Wenn wir IaaS verwenden, definieren wir virtuelle Maschinen, um unseren Code zu hosten. Mit PaaS sind wir noch weiter von der Hardware entfernt und verwenden die von uns ausgewählten Services und APIs, um ein geeignetes Leistungsniveau für unsere Anwendungen und Budgets auszuwählen. Mit container-basierten Architekturen wie Kubernetes befinden wir uns an einem Punkt dazwischen: Mithilfe von Diensten wie AKS können wir die zugrunde liegenden virtuellen Maschinen definieren, die dann unsere Container-Pods hosten und mit Änderungen an Rechenleistung und Speicher skalieren (und jetzt mit KEDA (Kubernetes-basierte ereignisgesteuerte automatische Skalierung), nach Empfang von Ereignissen).

Das ist nur ein Aspekt der Abstraktion. Kubernetes Microservices sind im Herzen staatenlos; Sie verwenden externen Speicher und sitzen entweder auf physischen oder virtuellen Netzwerken. Der Netzwerkaspekt beim Ausführen von Kubernetes ist wahrscheinlich der schwierigste: Wenn Dienste skaliert und verkleinert werden, müssen Sie Ihr Netzwerk so ändern, dass es den Änderungen an Ihrer Anwendung entspricht. Aber wie halten Sie Dienste in Verbindung, wenn ein Anwendungs-Front-End und ein Back-End möglicherweise unterschiedlich schnell skaliert werden?

Hier kommen Service-Meshes ins Spiel. Sie sind eine neue Abstraktionsebene, die Ihren Code vom zugrunde liegenden Netzwerk abhebt, indem sie die Funktionen eines modernen softwaredefinierten Netzwerks nutzen. Ein Service-Mesh fungiert als eine Reihe von Netzwerk-Proxys, die mit Ihrem Code bereitgestellt werden, und verwaltet die Service-zu-Service-Kommunikation, ohne dass Ihr Code das zugrunde liegende Netzwerk kennt. Sie können sich ein Service-Mesh als automatisierte Steuerebene für das Netzwerk Ihrer Anwendung vorstellen und die zugrunde liegende Steuerebene verwalten, während Kubernetes Ihren Code nach oben und unten skaliert.

Ein softwaredefiniertes Netzwerk für Microservices

Ein Service-Mesh ist im Grunde genommen ein verteilter Router mit dynamischen Routing-Regeln, die im Rahmen einer Kubernetes-Bereitstellung verwaltet werden. Sie können zusätzliche Regeln definieren. B. Produktions- und Testsysteme getrennt zu halten oder die Bereitstellung einer neuen Version und den Wechsel zwischen Containerversionen zu handhaben. Jeder Pod in einer Anwendung verfügt über eine Service-Mesh-Instanz, die als Sidecar ausgeführt wird. Die Serviceerkennung und andere statusbehaftete Elemente werden außerhalb Ihrer Services ausgeführt.

Mit einem Service-Mesh verschieben Sie Informationen in eine neue Netzwerkschicht, sodass Sie sie nicht in Ihre Microservices integrieren müssen. Müssen Sie eine Verbindung verschlüsseln? Das ist ein Job für Ihr Service-Mesh. Müssen Sie Kunden autorisieren? Eine weitere Aufgabe für das Service-Mesh.

Zu viele Maschen

Die Kombination einer Kubernetes-Bereitstellung mit einem Service-Mesh ist sehr sinnvoll. Es gibt jedoch noch ein großes Problem: Welches verwenden Sie? Gesandte? Istio? Linkerd? Aspen Mesh? Wenn Sie sich für eines entschieden haben, was hindert ein Entwicklungsteam in einem anderen Teil Ihres Unternehmens daran, ein anderes zu wählen? Was passiert dann, wenn Ihr Unternehmen beschließt, auf einer bestimmten Plattform zu standardisieren?

Das ist das Problem, das Microsoft mit der Service Mesh-Schnittstelle lösen möchte. Anstatt dass jedes Service-Mesh über einen eigenen Satz von APIs verfügt, können mit dem SMI gemeinsame APIs implementiert werden, die über verschiedene Service-Meshs hinweg funktionieren und das neue intelligente Netzwerk verwalten. Anstatt Ihren Code an ein bestimmtes Service-Mesh und seine APIs zu binden, können Sie über eine gemeinsame API Code schreiben, der die häufigsten Anwendungsfälle behandelt. Wenn Sie ein Service-Mesh austauschen müssen - wenn Sie den Anbieter wechseln oder einen finden, der besser funktioniert -, müssen Sie Ihren Code nicht ändern, solange das Service-Mesh das SMI implementiert. Alles, was Sie tun müssen, ist, Ihre Service-Mesh-Sidecars zu ändern und Ihren Code erneut bereitzustellen.

SMI: Common Service Mesh APIs

In Zusammenarbeit mit Kubernetes-Ökosystemunternehmen wie Hashicorp und Buoyant hat Microsoft die Hauptfunktionen für SMI definiert, die allgemeine Anforderungen seiner Kunden unterstützen. In der ersten Version wurden drei Bereiche behandelt: Verkehrspolitik, Verkehrstelemetrie und Verkehrsmanagement. Diese drei Bereiche werden von den meisten Service-Meshes gesteuert. Ziel ist es, eine Spezifikation zu erstellen, die einfach zu implementieren ist, ohne die zugrunde liegende Anwendung zu ändern.

Indem Sie SMI zu einer Reihe von Standard-APIs machen, hindert nichts Service-Mesh-Anbieter daran, weiterhin eigene APIs oder zusätzliche Funktionen außerhalb der angegebenen anzubieten. Alternativ müssen sie keine Änderungen vornehmen. Dritte können Übersetzungsebenen erstellen, die zwischen SMI-APIs und proprietären Service-APIs liegen. Sie benötigen auch keine neue Version von Kubernetes, da die SMI-APIs als Erweiterungs-API-Server und benutzerdefinierte Ressourcendefinitionen implementiert sind. Sie können sie mithilfe vorhandener Verwaltungstools in einem beliebigen Cluster installieren. Dies sollte es Azure und anderen in der Cloud gehosteten Kubernetes-Diensten erleichtern, SMI in ihre vorhandenen verwalteten Kubernetes-Dienste zu integrieren.

Unabhängig davon, ob Sie Linkerd oder Aspen Mesh oder das NSX Service Mesh von VMware verwenden möchten, können Sie mit SMI das von Ihnen bevorzugte auswählen, um die Code-Portabilität zu verbessern und die Bindung an bestimmte Cloud-Dienste zu vermeiden. Dann besteht die Möglichkeit, Service-Meshes zu wechseln, ohne Ihren Code zu beeinflussen. Wenn ein neues Service-Mesh eine bessere Leistung bietet, müssen Sie lediglich Ihre Build-Pipeline ändern, um das neue Mesh zu verwenden, und anschließend eine aktualisierte Anwendung bereitstellen.

Es ist interessant zu sehen, wie Microsoft bei einem Projekt wie diesem die Führung übernimmt und mit einem breiten Querschnitt der Kubernetes-Community zusammenarbeitet. Durch einen Ansatz, der explizit nicht auf das Erstellen eines Service-Meshs ausgerichtet ist, kann Azure im Rahmen der Konfiguration von AKS verschiedene Service-Meshes anbieten, sodass Sie das gewünschte Tool auswählen können, ohne Code ändern zu müssen.