Eine Einführung in Service Meshes

Ein Service Mesh ist eine Infrastrukturebene, mit der Sie die Kommunikation zwischen den Microservices Ihrer Anwendung verwalten können. Da immer mehr Entwickler mit Microservices arbeiten, haben sich Service-Meshes entwickelt, um diese Arbeit zu vereinfachen und effektiver zu gestalten, indem gemeinsame Verwaltungs- und Verwaltungsaufgaben in einer verteilten Konfiguration zusammengefasst werden.

Um einen Microservice-Ansatz für die Anwendungsarchitektur zu verfolgen, müssen Sie Ihre Anwendung in eine Sammlung lose gekoppelter Dienste aufteilen. Dieser Ansatz bietet bestimmte Vorteile: Mithilfe einer größeren Auswahl an Tools und Sprachen können Teams Entwürfe iterieren und schnell skalieren. Auf der anderen Seite stellen Mikrodienste neue Herausforderungen an die Komplexität des Betriebs, die Datenkonsistenz und die Sicherheit.

Service-Meshes sind darauf ausgelegt, einige dieser Herausforderungen zu bewältigen, indem sie eine differenzierte Kontrolle darüber bieten, wie Services miteinander kommunizieren. Insbesondere bieten sie Entwicklern die Möglichkeit, Folgendes zu verwalten:

Obwohl es möglich ist, diese Aufgaben nativ mit Container-Orchestratoren wie Kubernetes auszuführen, erfordert dieser Ansatz im Vergleich zu Service-Mesh-Lösungen wie https mehr Entscheidungsfindung und Administration im Voraus: //istio.io/[Istio] und Linkerd bieten ein Standardangebot. In diesem Sinne können Service-Meshes die Arbeit mit allgemeinen Komponenten in einer Microservice-Architektur rationalisieren und vereinfachen. In einigen Fällen können sie sogar die Funktionalität dieser Komponenten erweitern.

Service Meshes wurden entwickelt, um einige der Herausforderungen zu bewältigen, die mit verteilten Anwendungsarchitekturen verbunden sind.

Diese Architekturen sind aus dem dreischichtigen Anwendungsmodell hervorgegangen, das Anwendungen in eine Webschicht, eine Anwendungsebene und eine Datenbankebene aufteilte. In der Größenordnung hat sich dieses Modell als Herausforderung für Unternehmen erwiesen, die ein schnelles Wachstum verzeichnen. Monolithische Anwendungscodebasen können unhandlich werden [Big Balls of Mud], was die Entwicklung und Bereitstellung vor Herausforderungen stellt.

Als Reaktion auf dieses Problem entwickelten Unternehmen wie Google, Netflix und Twitter interne Fat Client-Bibliotheken, um die Laufzeitvorgänge für alle Dienste zu standardisieren. Diese Bibliotheken boten Load Balancing, Circuit Breaking, Routing und Telemetrie - Vorläufer für die Wartung von Mesh-Funktionen. Sie schränkten jedoch auch die Sprachen ein, die Entwickler verwenden konnten, und erforderten dienstübergreifende Änderungen, wenn sie selbst aktualisiert oder geändert wurden.

Ein Mikroservice-Design vermeidet einige dieser Probleme. Anstatt über eine große, zentralisierte Anwendungscodebasis zu verfügen, verfügen Sie über eine Sammlung diskret verwalteter Dienste, die ein Merkmal Ihrer Anwendung darstellen. Zu den Vorteilen eines Microservice-Ansatzes gehören:

Gleichzeitig haben Microservices auch Herausforderungen geschaffen:

Service-Meshes wurden entwickelt, um diese Probleme zu lösen, indem sie eine koordinierte und differenzierte Kontrolle über die Kommunikation von Services bieten. In den folgenden Abschnitten wird erläutert, wie Service-Meshes die Service-zu-Service-Kommunikation durch Serviceerkennung, Routing und internen Lastenausgleich, Datenverkehrskonfiguration, Verschlüsselung, Authentifizierung und Autorisierung sowie Metriken und Überwachung erleichtern. Wir werden Istios Bookinfo-Beispielanwendung - vier Mikrodienste, die zusammen Informationen zu bestimmten Büchern anzeigen - als konkretes Beispiel verwenden, um die Funktionsweise von Servicegittern zu veranschaulichen.

In einem verteilten Framework muss bekannt sein, wie eine Verbindung zu Diensten hergestellt wird und ob diese verfügbar sind oder nicht. Serviceinstanzpositionen werden dynamisch im Netzwerk zugewiesen und die Informationen über sie ändern sich ständig, wenn Container durch automatische Skalierung, Upgrades und Fehler erstellt und zerstört werden.

In der Vergangenheit gab es einige Tools für die Serviceerkennung in einem Microservice-Framework. Schlüsselwertspeicher wie etcd wurden mit anderen Tools wie Registrator gepaart, um Service-Discovery-Lösungen anzubieten. Tools wie Consul wiederholten dies, indem sie einen Schlüsselwertspeicher mit einer DNS-Schnittstelle kombinierten, über die Benutzer direkt mit ihrem DNS-Server oder -Knoten arbeiten können.

In ähnlicher Weise bietet Kubernetes standardmäßig eine DNS-basierte Diensterkennung an. Mit diesem Dienst können Sie Dienste und Dienst-Ports nachschlagen und IP-Lookups unter Verwendung allgemeiner DNS-Namenskonventionen rückgängig machen. Im Allgemeinen entspricht ein A-Datensatz für einen Kubernetes-Dienst diesem Muster: + .. svc.cluster.local. Sehen wir uns an, wie dies im Kontext der Bookinfo-Anwendung funktioniert. Wenn Sie beispielsweise Informationen zum Dienst "+ details +" in der Bookinfo-App wünschen, können Sie sich den entsprechenden Eintrag im Kubernetes-Dashboard ansehen:

Bild: https: //assets.digitalocean.com/articles/service_mesh_intro/details_svc_k8.png [Details Service in Kubernetes Dash]

Auf diese Weise erhalten Sie relevante Informationen über den Dienstnamen, den Namespace und "+ ClusterIP +", mit denen Sie eine Verbindung zu Ihrem Dienst herstellen können, selbst wenn einzelne Container zerstört und neu erstellt werden.

Ein Service-Mesh wie Istio bietet auch Service-Discovery-Funktionen. Für die Serviceerkennung stützt sich Istio auf die Kommunikation zwischen der Kubernetes-API, der Istio-eigenen Steuerebene, die von der Verkehrsmanagementkomponente Pilot und verwaltet wird Die Datenebene wird von Envoy Sidecar-Proxies verwaltet. Pilot interpretiert Daten vom Kubernetes-API-Server, um Änderungen an Pod-Positionen zu registrieren. Diese Daten werden dann in eine kanonische Istio-Darstellung umgewandelt und an die Stellvertreter des Beiwagens weitergeleitet.

Dies bedeutet, dass die Serviceerkennung in Istio plattformunabhängig ist. Dies können wir anhand des Istio-Add-ons Grafana feststellen Details + `Service erneut im Service-Dashboard von Istio:

Bild: https://assets.digitalocean.com/articles/service_mesh_intro/details_svc_istio.png [Details Service Istio Dash]

Unsere Anwendung wird auf einem Kubernetes-Cluster ausgeführt, sodass wir wieder die relevanten DNS-Informationen zum + details + -Dienst sowie andere Leistungsdaten anzeigen können.

In einer verteilten Architektur ist es wichtig, aktuelle, genaue und leicht auffindbare Informationen zu Diensten zu haben. Sowohl Kubernetes als auch Service Meshes wie Istio bieten Möglichkeiten, diese Informationen mithilfe von DNS-Konventionen abzurufen.

Beim Verwalten des Datenverkehrs in einem verteilten Framework wird gesteuert, wie der Datenverkehr zu Ihrem Cluster gelangt und wie er zu Ihren Diensten geleitet wird. Je mehr Kontrolle und Spezifität Sie bei der Konfiguration des externen und internen Datenverkehrs haben, desto mehr können Sie mit Ihrem Setup tun. In Fällen, in denen Sie beispielsweise mit Canary-Bereitstellungen arbeiten, Anwendungen auf neue Versionen migrieren oder bestimmte Dienste durch Fehlerinjektion einem Stresstest unterziehen, ist es entscheidend, zu entscheiden, wie viel Verkehr Ihre Dienste erhalten und woher er kommt der Erfolg Ihrer Ziele.

Kubernetes bietet verschiedene Tools, Objekte und Dienste, mit denen Entwickler den externen Datenverkehr zu einem Cluster steuern können: +kubectl Proxy + `, https://kubernetes.io/docs/concepts/services-networking/service/nodeport [