Istio
Istio ist eine unabhängige Open-Source-Service-Mesh-Technologie, mit der Entwickler eine verteilte Microservice-Architektur (MSA) unabhängig von Plattform, Quelle oder Anbieter verbinden, sichern, steuern, beobachten und ausführen können. Istio verwaltet Service-Interaktionen sowohl für Container- als auch für VM-basierte (virtuelle Maschine) Workloads.
Google, IBM und Lyft haben Istio im Mai 2017 gestartet, um die Compliance- und Sicherheitsherausforderungen zu bewältigen, die sich bei der Integration anwendungsbasierter Microservices in verteilten Systemen ergeben. Die erste Version wurde für die Verwendung in einer Kubernetes-Clusterumgebung entwickelt. Istio hat seitdem Unterstützung für Nomad- und Consul-Cluster hinzugefügt.
Istio wurde entwickelt, um Entwicklern dabei zu helfen, den Verlust an Beobachtbarkeit und Kommunikations- sowie Interaktionskontrolle zu überwinden, der mit einer größeren Anzahl von Microservices auftritt. In traditionellen Architekturen lösten Entwickler Probleme in verteilten Systemen, indem sie Änderungen am Anwendungscode vorgenommen oder (sprachspezifische) Client-Bibliotheken erstellt haben.
Istio fungiert als Infrastrukturschicht zwischen dem Anwendungsdienst und dem Netzwerk, um eine einheitliche (nicht sprachspezifische) Möglichkeit zum Steuern von Microservices bereitzustellen.
So funktioniert Istio
Ein Netzwerk von Microservices und deren Wechselwirkungen wird als Service-Mesh bezeichnet. Ein Service-Mesh ermöglicht Einblicke in Service-Kommunikationsschichten und bietet eine bessere Kontrolle der Microservice-Kommunikationslogik. Wenn ein Service-Mesh wächst, wird es jedoch schwieriger zu verstehen, wie jeder Microservice mit den anderen interagiert. Dies ist, was Istio zu lösen versucht. Es verschiebt die Logik aus dem Anwendungscode in das Service-Mesh, sodass Entwickler Services für jeden Microservice unabhängig und mit wenigen oder keinen Codeänderungen skalieren und bereitstellen können.
Die Elemente von Istio umfassen:
- Envoy – Istio verwendet eine erweiterte Version von Envoy, einem Proxy- und Kommunikationsbus auf Anwendungsebene, der für SOA (Serviceorientiert Architektur) entwickelt wurde. Istio stellt neben jeder Anwendungsinstanz ein Envoy Sidecar bereit. Envoy wurde ursprünglich für Lyft entwickelt. Der Taxianbieter erhält über Istio den Zugriff auf detaillierte Informationen zum Straßenverkehr.
- Pilot – Pilot steuert das Istio-Servicenetz und bietet Serviceerkennung für Envoy Sidecars sowie Verkehrsmanagement, zum Beispiel für A/B-Tests, Testbereitstellungen und Timeouts.
- Citadel – Dies ist die Sicherheitskomponente des Istio-Service-Mesh. Mit Citadel kommunizieren Dienste miteinander und Entwickler aktualisieren unverschlüsselten Datenverkehr über das Service Mesh, um sicherzustellen, dass er beim Hin- und Herbewegen verschlüsselt ist. Citadel bietet eine sichere Service-to-Service-Authentifizierung mit integrierter Identitäts- und Zugriffsverwaltung (IAM, Identity Access Management).
- Mixer – Mixer ist der plattformunabhängige zentrale Punkt, der die Telemetrie von jedem Envoy-Proxy erfasst und an Zugriffssteuerungsrichtlinien durchsetzt. Mixer ist stackable und ermöglicht das Hinzufügen von Anwendungen von Drittanbietern.
Ein Istio-Service-Mesh wird in zwei Ebenen aufgeteilt: die Datenebene (Data Plane, DP) und die Steuerebene (Control Plane, CP). Auf der DP befindet sich eine Reihe intelligenter Proxys, die als Sidecars dienen, um neben Mixer die Netzwerkkommunikation zwischen Microservices zu steuern.
Die Control Plane ist Istios Kern. Es sichert die Data Plane und verwaltet und konfiguriert Proxys, um den Datenverkehr weiterzuleiten und Richtlinien zur Laufzeit durchzusetzen. Die Steuerebene konfiguriert Mixer auch so, dass er Telemetrie erfasst und Richtlinien anwendet. Es verfügt über ein Sieben-Layer-Verständnis und kann den DP darin schulen, komplexe Steuerungsentscheidungen zu treffen in Abhängigkeit von Sicherheitseinstellungen, konstanten Telemetriedaten und weiteren Umständen.
Zu den Funktionen von Istio gehören:
- Automatischer Lastenausgleich – Der Lastausgleich ermöglicht die Kontrolle des HTTP-, gRPC-, WebSocket- und TCP-Austauschs über die Kommunikation zwischen Microservices. Istio unterstützt derzeit drei Modi für Enyoy Load Balancer: Round Robin, Random und Weighted Least Request.
- Feinkontrolle des Traffic – Mit der granularen Kontrolle können Entwickler Routing-Regeln, Wiederholungsversuche, Failover und Fault Injection anwenden und gleichzeitig die Funktionsweise der einzelnen Microservices steuern, statt Codeänderungen vorzunehmen, die alle Microservices gleichzeitig betreffen.
- Zugriffskontrolle – Die Sicherheitsarchitektur von Istio umfasst eine transparente TLS-Verschlüsselung (Transport Layer Security) sowie eine starke identitätsbasierte Authentifizierung, Autorisierung und Abrechnung (AAA) für jeden Microservice.
- Sichtbarkeit – Istio bietet Einblick in den Clusterverkehr durch Protokollierung, grafische Darstellung, automatische Metriken und Ablaufverfolgungsfunktionen.
Wozu verwenden Unternehmen Istio?
Die von Istio bereitgestellten Services wie Load Balancer, Überwachung und Verwaltung reduzieren die Komplexität von Microservice-Bereitstellungen. Da alle Features und Funktionen in verschiedenen Bibliotheken verfügbar sind, verringert Istio die Belastung, indem es Veränderungen an der Kommunikation der Diente erlaubt, ohne den Quellcode zu ändern, sodass Entwickler Objekte auf Serviceebene effizienter und effektiver überwachen, festlegen und durchsetzen können (SLOs). Das erhöht auch die Geschwindigkeit beim Erkennen und Beheben von Problemen.
Das Verkehrsmanagement von Istio vereinfacht die Konfiguration von Service-Level-Eigenschaften und bietet mehr Einblick in den Traffic und die mitgelieferten Fehlerbehebungsfunktionen. Auf diese Weise können Entwickler Schwachstellen erkennen, bevor sie zu Problemen werden, wodurch Reaktionen zuverlässiger und das Netzwerk sicherer werden.
Istio verbessert die Sicherheit weiter, indem es die Authentifizierung, Autorisierung und Verschlüsselung der Servicekommunikation verwaltet. Richtlinien lassen sich über verschiedene Laufzeiten und Protokolle hinweg durchsetzen, da Istio standardmäßig die Dienstkommunikation sichert. Dadurch können sich Entwickler auf die Anwendungsebene konzentrieren.
Darüber hinaus sorgt die verbesserte Sichtbarkeit von Istio für eine einfachere Nachverfolgung, Überwachung und Protokollierung und somit ein besseres Verständnis der Auswirkungen von Service-Performance auf Elemente im gesamten System. Die benutzerdefinierten Dashboards gewähren einen Überblick darüber, wie sich eine bestimmte Leistungsmetrik auf andere Prozesse auswirkt.
Istio und Kubernetes
Istio ist plattformunabhängig; das erleichtert die Zusammenarbeit mit der Kubernetes-Engine. Durch die gemeinsame Verwendung der beiden Funktionen kann die Service-to-Service- und Pod-to-Pod-Kommunikation auf Anwendungs- und Netzwerkebene gesichert werden.
Kubernetes profitiert auch von einer Partnerschaft mit Istio. Die Container-Orchestrierungssoftware von Kubernetes kann Workloads mit mehreren Containern wie Microservices verarbeiten, beherrscht jedoch keine Funktionen wie Verkehrsmanagement und Fehlerbehandlung. Istio füllt diese Lücken und schafft ein effizienteres und sichereres System.
Istio versus Linkerd
Linkerd ist ein weiteres Open-Source-Service-Mesh, das im Wettbewerb mit Istio steht. Ein unmittelbarer Unterschied zwischen beiden ist die in der Datenebene verwendete Proxy-Technologie. Während Istio Envoy als Proxy verwendet, verwendet Linkerd einen speziellen Proxy namens Linkerd-Proxy. Istios Envoy-Proxy ist in C++ geschrieben und der Linkerd-Proxy ist in der Programmiersprache Rust erstellt. Darüber hinaus baut Istio auf Envoy auf und bietet den Vorteil wesentlicher Funktionen wie das Routing von Teilmengen.
Ein weiterer wichtiger Unterschied besteht darin, dass das Linkerd-Service-Mesh mit einer Kubernetes-Denkweise erstellt wird, während Istio sowohl für Kubernetes-Umgebungen als auch für Nicht-Kubernetes-Umgebungen geeignet ist. Daher kann Linkerd nur in Kubernetes-Umgebungen ausgeführt werden
