Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Service Meshes in Microservice Architekturen

301 views

Published on

Fachposter, 2019: Erstellt von QAware in Zusammenarbeit mit Prof. Dr. Kratzke, Technische Hochschule Lübeck und ObjektSpektrum (Verlag: SIGS DATACOM).

Bestellbar unter https://www.sigs-datacom.de/order/poster/Service-Mesh-Poster-2019.php

(Dokument bitte herunterladen für bessere Lesbarkeit)

Published in: Data & Analytics
  • Ich kann eine Website empfehlen. Er hat mir wirklich geholfen. ⇒ www.WritersHilfe.com ⇐ Zufrieden und beeindruckt.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Service Meshes in Microservice Architekturen

  1. 1. www.opitz-consulting.comwww.opitz-consulting.com Service Meshes in Microservice Architekturen Transparente Sicherheit, Beobachtbarkeit und Zuverlässigkeit für Cloud-native Anwendungen Inhaltliche Entwicklung: Prof. Dr. Nane Kratzke, Technische Hochschule Lübeck, Mönkhofer Weg 239, 23562 Lübeck Inhaltliche Mitwirkung: Dr. Josef Adersberger, QAware GmbH Center of Excellence IT-Probleme lösen. Digitale Zukunft gestalten. WOZU EIGENTLICH SERVICE MESHES? Die Entwicklung und Betrieb eines einzelnen Microservice ist zwar einfach ( GAINS), der Betrieb komplexer Service-of-Service Systeme bringt aber im Gegenzug diverse weitere Herausforderungen mit sich ( PAINS). Service Meshes lösen diese Herausforderungen außerhalb einer Applikation in einer explizit dafür vorgesehenen Schicht. EXKURS: SIDECAR Anwendungen und Dienste benötigen häufig zusammengehörige Funktionen, wie z. B. Überwachung, Protokollierung, Konfiguration, etc.. Solche kohärenten Peripherieaufgaben können als separate Komponenten oder Dienste implemen­tiert werden. Werden diese Aufgaben in einem eigenen Prozess oder Container bereitgestellt, um Plattformdienste sprachübergreifend bereitzustellen, spricht man von einem Sidecar. Proxies in Service Meshes werden häufig als Sidecars in Containern bereitgestellt, die jeder Serviceinstanz zur Seite gestellt werden. Ein Service Mesh besteht aus einer Kontrollebene (Control plane), die Proxies steuert. Die Proxies sind Serviceinstanzen zugeordnet (Sidecar Pattern) und spannen eine verschlüsselte Datenschicht (Data plane) für Services auf. Architektur eines Service Meshes SERVICE B Telemetry Security CONTROLPLANE CONTAINER PLATFORMS Kubernetes Swarm Mesos … … … BACKENDS Prometheus Jaeger Zipkin … … … SERVICE A CONTROL PLANE • Verwaltung von Routen und Regeln • Konfiguration von Timeouts, Retries, etc. • Service Discovery • Access Control • Policy Control • Telemetriedaten TLS certs to proxies policy checks, telemetry External Service Request (physical) HTTP, gRPC, TCP (TLS optional) External service request (logical) Service to service communication (logical) Service-to-Service Communication (physical) HTTP, gRPC, TCP (TLS optional) Config data to proxies Service Discovery Proxy SvcB - Pod 1 Proxy SvcB - Pod 2 Proxy SvcB - Pod 3 Proxy SvcB - Pod 4 Current Version Canary Version Proxy SvcB - Pod 1 Proxy SvcB - Pod 2 Proxy SvcB - Pod 3 Proxy SvcB - Pod 4 Current Version Canary Version SERVICE B SERVICE B User-agent: Android User-agent:iPhone Logging & Tracing settings Telemetry Security CONTROLPLANE Service Discovery Offers Svc Products Svc Proxy OPERATOR Sales Svc Orders Svc Users Svc Proxy Proxy Traces z. B. Jaeger Monitoring z. B. Prometheus PAINS OF MICROSERVICES • Inhärente Komplexität • Geschäftslogik ist über voneinander unabhängige Microservices verteilt • Sicherheit (Zugriffskontrolle und vergrößerte Attack Surfaces) • Verteiltes Logging, Traceability GAINS OF MICROSERVICES • Einfache Entwicklung (einzelner) Microservices • Bounded Contexts und Domain Driven Design sind näher an der Denkweise der Fachabteilung • Cloud-native und DevOps by design • Unabhängiges Deployment (kein Downtime durch monolithische Rollouts) • Einfache Integration in Continuous Integration und Continuous Deployment Pipelines DEFINITION Service Meshes erzeugen eine Netzwerkabstraktion für containerbasierte Applikationen und Dienste, um deren Management zu vereinfachen und Aspekte wie Traffic Management, Zuver­lässigkeit, Beobacht- barkeit und Sicherheit innerhalb von Microservice- basierten Architekturen zu vereinfachen. ? TRAFFIC-MANAGEMENT UND ZUVERLÄSSIGKEIT • Last- und zustandsadaptives Service Discovery • Mit einem selbstheilendem System Design • Ermöglicht intelligentes (adaptives) Routing • A/B tests, Canary Deployments, schrittweises Rollout, etc. • Traffic-Splitting/Steering SERVICE A SERVICE A SvcA Proxy SvcA Proxy 5% 95% TRAFFIC MANAGEMENT • Dynamisches regelbasiertes Routing • Regel- und volumenbasiertes Traffic Splitting • Rate Limit • Quotas ZUVERLÄSSIGKEIT DURCH RESILIENZ-PATTERNS • Circuit-Breaker • Timeouts + Retries • Recovery • Latenzbasiertes Load Balancing • Health-aware Service DiscoveryPROXY • Jeder Dienst kommuniziert über einen dedizierten Proxy (Sidecar Pattern). • Die gesamte Kommunikation im Mesh erfolgt über diese Proxies. • Proxies können so das Kommunikationsverhalten anreichern und z.B. Tracing- und Monitoring-Daten sammeln. • Proxies lassen sich bequem von Orchestrierungs-Frame- works verwalten, um so z. B. bei jedem Deployment automatisch platziert zu werden. DATA PLANE • Eingehende (ingress) und ausgehende (egress) Kommunikation • Service-to-Service Kommunikation • Kommunikation über Proxies • Transparent für verwaltete Dienste TELEMETRIE UND BEOBACHTBARKEIT Telemetriedaten werden transparent durch die Proxies des Service Meshes gesammelt, um Latenz-, Zustands und Volumen-basiertes Load Balancing und Traffic-Management zu ermöglichen. Dies er- möglicht Resilienz und Beobachtbarkeit. • Tracing • Monitoring • Logging • Erfassung von Telemetriedaten GÄNGIGE FEATURES VON SERVICE MESHES Traffic Management Resiliency Security Observability • Request Routing • Load Balancing • Traffic Shifting • Traffic Mirroring • Service Discovery • Ingress, Egress • API Specification • Multicluster Mesh • Timeouts • Circuit Breaker • Health Checks • Retries • Rate Limiting • Delay Fault Injection • Connection Pooling • mTLS • Role-Based Access Control • Workload Identity • Authentication Policies • CORS Handling • TLS Termination • Metrics • Logs • Traces SICHERHEIT Service Meshes folgen häufig einem Secure-by- Default Ansatz und realisieren so eine für Services transparente Verschlüsselung des Datenverkehrs. Ferner werden Kommunikationsregeln flexibler und auf Basis von Serviceidentitäten (logisch) anstatt mittels Network Controls (physisch) durchgesetzt. • Authentifizierung (Service-to-Service und End-User) • Authorisation (Service-to-Service und End-User) • Identitäts- und Credential-Management • Transparante Verschlüsselung der Service Communication • Transparentes Zertifikat Handling (TLS) • TLS Endpunkt Termination BEISPIELE FÜR SERVICE MESHES UND PROXIES • Linkerd • Istio • Consul • Kong • Traefik • Envoy • NGINmesh … OPERATOR Rules Telemetry Security CONTROLPLANE Service Discovery Sales Svc Offers Svc Users Svc Products Svc Service discovery Routes Traffic rules Proxy Proxy OPERATOR Telemetry Security CONTROLPLANE Service Discovery Sales Svc Orders Svc Offers Svc Users Svc Products Svc TLS certificates Certificate settings Proxy OPERATOR Proxy Proxy ProxyProxy Proxy Con A Proxy Proxy Con A Proxy Proxy Proxy Orders Svc Proxy

×