Immer mehr Unternehmen setzen für ihre Cloud-Services auf Kubernetes. Somit steigt die Gefahr im Betrieb, schnell die Übersicht zu verlieren und die IT-Sicherheit des Datenverkehrs nicht mehr gewährleisten zu können. Ein Service-Mesh mit Istio kann helfen.
Sobald Unternehmen auf eine Cloud-Strategie setzen, stellt sich schnell der Bedarf nach hochverfügbaren Applikationen. Unweigerlich werden die Entwickler in die Welt der Microservices und Kubernetes geschleudert. Kaum sind die ersten Schritte und Erfolge im Unternehmen spürbar, wächst der Appetit nach mehr. Eine Vielzahl von Microservices kann auch den erfahrensten Softwareentwickler aus der Fassung bringen. Das kann ganz schön unübersichtlich und kompliziert werden! Wie kann die Flut von Microservices noch sinnvoll überwacht und die Sicherheit des Datenverkehrs gewährleisten werden?
Sobald eine Applikation in Form von Microservices auf einem Kubernetes Cluster bereitgestellt werden, ist ein Service-Mesh ein „Must have“. Um Istio zu verstehen, müssen wie erst verstehen was ein Service-Mesh ist.
Wozu ein Service-Mesh?
Die Stärke einer Microservice-Architektur ist die lose Kopplung der Applikationsteile. Gleichzeitig ist es auch ein Nachteil, denn in jedem Microservice müssen Funktionen wie Monitoring, Tracing uvm. gelöst werden. Ein Service Mesh verspricht, viele der Funktionen gleich in der Infrastruktur zu lösen. Ein Service-Mesh hilft dem Betreiber einer cloud-native Applikation, die z.B. auf der Open Source Container Orchestrierungs-Plattform OpenShift (resp. Kubernetes) betrieben wird, die Kontrolle zu behalten. Hierbei bietet Istio Funktionen, wie den Datenverkehr zu verschlüsseln. Das richtige Leiten des Datenverkehrs durch definierte Regeln. Software-Logik an eine Netzwerk-Infrastruktur abgeben.
Kernfunktionen:
- Sichern und verschlüsseln der Kommunikation zwischen den Microservices (Security)
- Identifizieren, wie die Services kommunizieren, miteinander verbunden sind (Traffic Routing) und die Systemstabilität erhöhen (Hardening / Circut Breaking)
- Beobachten, wie sich die Anwendung „End-To-End“ verhält. (Monitoring). Hierbei geht es nicht nur darum, ob die Services „up“ oder „down“ sind, sondern die Identifikation von Schwachstellen in der Service-Architektur und wie der Datenverkehr durch die Applikation bzw. Microservices „fliesst“.
- Überwachen und kontrollieren, welcher Service hat Zugriff auf welchen Service und wie soll sich im Falle einen Unterbruchs, der Service verhalten.
In Abbildung 1 zu erkennen, kommunizieren nicht die Services direkt miteinander. Die Kommunikation übernehmen die Proxys von Envoy. Diese Proxys senden kontinuierlich Telemetriedaten an das Istio Control Plane.
Architekturen, früher versus heute
Hersteller von Web-Applikationen mussten eine derartige Logik direkt in der Anwendung entwickeln. Dies hat einen direkten Kosteneinfluss auf die Herstellung. Auch haben solche integrierten Services den Entwicklungszyklus von Anwendung deutlich verlangsamt. Ebenso waren diese Services wesentlich grösser und durch den monolithischen Aufbau deutlich weniger flexibel für Anpassungen und aufwendig im Betrieb.
Worin sollte heute der technologische und strategische Fokus einer containerbasierten Web-Applikation gelegt werden?
- Die Applikation schlank halten
- Die Applikation mehr auf das Kern-Business des Unternehmens fokussieren
- Software-Intelligenz in die Netzwerk-Infrastruktur implementieren
Fazit
Mit einem Service-Mesh lassen sich Microservices automatisiert überwachen, steigert die Resilienz und Sicherheit. Die Vorteile haben auch Schattenseiten wie eine höhere Latenz und höherer Ressourcenverbrauch. Die Vor- und Nachteile müssen also abgewogen werden.
Weiterführende Links zum Thema
- Red Hat: Was ist Service Mesh für OpenShift (EN)
- Mehr zu istio.io Service-Mesh
- Installationsanleitung für Istio
- Datenverkehr-Management verstehen
