Suche
Zwei Seiten der gleichen Medaille?

Microservices & DevOps: Sind Service-Meshes die nächste Generation der Software-Defined-Networks?

Wolfgang Kirchberger
SDN Logo

©Shutterstock / Profit_Image

Der technologische Wandel beschleunigt sich weiter. Viele Unternehmen migrieren in die Cloud, um von den dortigen Vorteilen zu profitieren: Skalierbarkeit, Flexibilität und Agilität. Aber die breite Einführung der Cloud hat – ebenso wie Mobility, das Internet der Dinge (IoT) oder Big Data Analytics-Anwendungen – tiefgreifende Auswirkungen auf die IT-Infrastrukturen.

Netzwerke und Services auf traditionelle Art und Weise zu implementieren ist unflexibel. Damit sind Organisationen nicht mehr in der Lage, flexibel auf neue Anforderungen zu reagieren. Um die Migration in die Cloud, egal, ob public, private oder hybrid, so reibungslos wie möglich zu gestalten, sollten Unternehmen ihre Netzwerke so aufbauen, dass diese die Vernetzung und Service-Anforderungen der immer dynamischer werdenden Anwendungen unterstützen.

Netzwerke müssen also konzeptbezogen, skalierbar, programmierbar und automatisiert sein. Software-Defined-Networks und ihre mögliche nächste Generation – Service-Meshes – erfüllen diese Voraussetzungen und gehen sogar schon darüber hinaus. Denn unabhängig davon, ob Unternehmen containerbasierte Ansätze verfolgen und/oder Funktionen-as-a-Service-Stacks implementieren – in der neuen Welt der Microservice-Architekturen gewinnt das Netzwerk immer stärker an Bedeutung.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Software-Defined und Service Meshes: DevOps-Überlegungen

Komplexität macht nicht bei den Microservices Halt. Hier hilft der DevOps-Ansatz, eine Anwendung über den gesamten Zyklus hinweg zu managen. Dazu gehören Entwicklung, Testing, Ausführung und Implementierung der Anwendung. Im nächsten Schritt sind auch kontinuierliche Integration, Auslieferung und Response mit einzubeziehen. Betrachten wir einige Erwägungen, die im Hinblick auf Service Meshes und DevOps zu Beginn getroffen werden sollten.

1. Mandantenfähigkeit / Multi-User-Umgebungen

In einem gemeinsamen Cluster sollte sich der Code nicht auf den Betriebskontext wie Operator oder Entwicklungs-/Test-Umgebung fokussieren. Um dies zu erreichen, werden Abschottungsmechanismen benötigt. Namespaces von Kubernetes und Role Based Access Control (RBAC) helfen dabei, sind aber nur der Anfang. Eine kurze Übersicht hinsichtlich des Routings in OpenContrail und Services Meshes hilft dabei, die Überlegungen für eine Kontext-Isolation deutlich zu machen.

OpenContrail für K8s Recap: Eine SDN-Herangehensweise an die Isolation sind Overlay-Netzwerkarchitekturen. Diese erlauben uns, virtuelle Netzwerke aufzubauen, die voneinander über das physische Netz getrennt sind (mit unterschiedlich gekennzeichneten Verkapselungen) – und oftmals auch im weiterleitenden Agenten. Dies ist der Fall bei OpenContrail, aber die Anwendung erlaubt auch übergeordnete, namespaces ähnliche Wrapper, die Domains/Tenants und Projects genannt werden. Domains sind voneinander getrennt, Projects sind innerhalb von Domains ebenfalls isoliert, genauso wie virtuelle Netzwerke innerhalb der Projects. Diese Hierarchie bildet isolierte Tenants und die Entwicklungs-, Test-, Ausführungs- und Produktionsumgebungen bestmöglich ab.

Ein virtuelles Netzwerk lässt sich anschließend dazu nutzen, jeden Microservice zu isolieren. Um Netzwerke zu verbinden (optional über Domains und Projects hinweg), wird eine Policy erstellt und auf die Netzwerke angewendet, die verbunden werden müssen. Eine solche Policy kann zum Beispiel Kommunikationsrichtung, Netzwerknamen, Ports und einzusetzende Service Chains (zum Beispiel einen stateful-Firewall-Service) spezifizieren.

Für Kubernetes lassen sich diese Domänen, Projekte und Netzwerke auf Annotations basierend entwickeln. OpenContrail verbindet Namespaces mit eigenen OpenContrail-Projekten oder eigenen virtuellen Netzwerken. Damit sind Microservices optional auf einem einzigen großen Netzwerk untereinander erreichbar (ähnlich des Standard-Cluster-Verhaltens). Um damit einhergehende Sicherheitsbedenken zu adressieren, ermöglicht OpenContrail, ACL-Regeln durchzusetzen und automatisiert zu erstellen. Mit dieser Methode werden Microservices für Security-Zwecke isoliert – basierend auf K8s Annotations oder Kubernetes Network Policy Objects, implementiert als OpenContrail-Sicherheitsgruppen und -regeln.

Lesen Sie auch: Docker, Kubernetes, OpenShift: Hype oder Revolution der IT?

Eine andere Art neuer Objectannotations wie K8s Implementierungen, Jobs oder Services legt die komplette OpenContrail-Domäne, das entsprechende Projekt und das virtuelle Netzwerk der Wahl fest. Die beste Herangehensweise ist eine Hierarchie, welche die DevOps Teams und die Architektur spiegelt. Die Umgebung nutzt das OpenContrail-Modell und segmentiert nach Domäne, Projekt und Netzwerk. Dies steht leider im Gegensatz zu der einfacheren und häufiger eingesetzten globalen Default-Deny-Regel und damit verbunden zu einer kontinuierlich wachsenden White List, welche jedes Cluster in einen Schweizer Käse verwandelt. Übersicht und Kontrolle zu behalten ist hier schwierig.

Das Overlay für SDN liegt auf den OSI-Ebenen 2, 3, und 4. Wenn das Paket am Knotenpunkt ankommt, empfängt es der vRouter (im Falle von OpenContrail), checkt den inneren Paketheader (die VXLAN ID oder MPLS LSP Label) – und ermittelt so Domäne/Tenant, Projekt und Netzwerk. Die ID bzw. das Label gibt sozusagen an, welche Routing-Tabelle als Lookup-Kontext für die Zieladresse genutzt wird. Anschließend wird das Paket (abhängig der Zugriffskontroll-Listen, ACLs) an den richtigen Container oder die korrekte Pod-Schnittstelle (per CNI-Standards) weitergeleitet.

Der Service Mesh Background: Sofern sie genutzt werden (was auch auf einer per-Microservice-Basis sein kann), wird bei den Istio-Envoy- und Linkerd-Modellen den Microservices ein Layer-7 Router und Proxy vorgeschaltet. Der gesamte Verkehr wird vom Proxy abgefangen und zwischen den Knotenpunkten getunnelt. Damit ist es ein Overlay auf einer höheren Ebene.

Das Layer-7 Overlay ist vom Konzept her das gleiche wie die SDN Overlays – mit der Ausnahme, dass das Overlay-Protokoll normalerweise HTTP, HTTP2 oder TLS mit einem der beiden ist. Im Linkerd DaemonSet-Implementierungsmodus gibt es eine IP-Adresse für den Host. Linkerd agiert dann als Proxy für den gesamten Verkehr. Dies ist konzeptionell dem vRouter ähnlich, in der Realität handhabt Linkerd allerdings nur HTTP-Traffic an bestimmten Ports und nicht den gesamten Verkehr. Dabei nutzt Linkerd das von Finagle übernommene Delegation-Tables-(dtabs-)Format für das Routing und die Zieladressauflösung.

Im Sidecar-Implementierungsmodell für Linkerd oder für Envoy von Istio (das immer ein Sidecar ist) ist der Proxy im gleichen Container-Netzwerk-Kontext wie jeder Microservice, da sie im gleichen Pod angesiedelt sind. Sie wenden dabei einige IP-Table-Tricks an, um sich zwischen die Applikation und das Netzwerk zu schieben. Das Traffic-Routing und die Ziel-Auflösung in Istio Pilot (die Control Plane) und Envoy (die Daten-Plane) basieren primär auf dem Kubernetes Service-Namen.

Vor diesem Hintergrund gibt es einige Implikationen für die Mandantenfähigkeit. Im SDN-Setup findet die Klassifizierung von Tenant, Umgebung und Applikation (Netzwerk) im Kernel vRouter statt. In Service-Mesh Proxies wird hingegen eine CNI-Lösung benötigt, die die Pakete zum Pod befördert. Für Linkerd sind dtab-Routing-Regeln notwendig, die Tenant, Umgebung und Service einbeziehen. Dtabs scheinen ein guter Weg zu sein, diese Ausgabe so herunterzubrechen, dass die sich bequem verwalten lässt. Im häufiger für Envoy eingesetzten Sidecar-Modus endet der Traffic meist in dem Pod, der bereits mit dem K8s Namespace verbunden ist. Damit lassen sich der Tenant oder die Umgebung außerhalb der Istio-Richtlinien abbilden – und IT-Teams können sich bei Envoy darauf beschränken, den Service-Namen einem Container und einem Port zuzuordnen.

OpenContrail erscheint als guter Weg, um die Hierarchien separater Teams abzubilden und RBAC- und Routing-Kontexte herauszubilden. Mit Linkerd dtabs lässt sich flexibel die benötigte Anzahl unterschiedlicher Ebenen von Routing-Interpretationen anlegen. Allerdings wird wahrscheinlich ein leistungsfähigerer RBAC benötigt, der es erlaubt, die dtabs unter den Team-Tenants hinsichtlich Sicherheit und Koordination aufzuteilen.

Istio isoliert Tenants oder Umgebungen kaum. Dies ist vermutlich nicht der Fokus der Anwendung, da Envoy immer ein Sidecar-Container ist und sowieso ein darunterliegendes, mandantenfähiges Netzwerk benötigt, um den Traffic auf den Sidecar-Pod zu leiten.

Ein weiterer Punkt ist, dass die Service-Discovery in die Service-Mesh-Lösungen integriert ist, aber noch immer hohe Relevanz in der SDN-Welt besitzt. Systeme mit DNS wie OpenContrail helfen dabei, die Name Resolution in mandantenfähiger Art und Weise zu verwalten und gleichzeitig IP-Adressen über die unterschiedlichen Umgebungen hinweg zu managen (sozusagen „Bring Your Own IPs“). Diese Voraussetzung bringen die meisten Service-Meshes nicht mit. Es mag aber hinsichtlich einer Reihe von Team- sowie Entwicklungs-, Test-, Ausführungs- und Produktionsumgebungen wünschenswert sein, die gleichen IP-Address-Management-Pools und Subnets zu haben.

2. Implementierung und Load Balancing

Im Hinblick auf die Implementierung und kontinuierliche Auslieferung (Continuous Delivery) ist es hilfreich, dass SDN sich programmieren lässt. Hier haben Service-Meshes aber einen Vorteil, da sie direkt mit Continuous Delivery im Blick entwickelt wurden. Für blau-grüne Implementierungen mit SDN hilft eine Floating-IP-Funktionalität. So können Entwickler auf grün (ein virtuelles IP auf eine neue Version des Microservice portieren) umschalten und sicher wieder auf blau zurück wechseln, sollte ein Problem auftauchen. Auch wenn kontinuierlich ausgeliefert oder kontinuierlich in Nicht-Liveumgebungen vorkonfiguriert wird, lässt sich dies über eine unterschiedliche Floating-IP-Adresse erreichen. OpenContrail handhabt überlappende Floating-IPs – und erleichtert IT-Teams damit die Arbeit.

Die Service-Mesh Routing-Regeln können das gleiche Ergebnis liefern, allerdings basierend auf Routing-Switchovers auf der HTTP-Ebene, die beispielsweise auf eine neuere Backend-Version verweisen. Darüber hinaus erlauben Service-Meshes einen Traffic-Roll-over: Sie zeigen zunächst einen niedrigen Prozentsatz des Verkehrs an und dann den kompletten Traffic. Damit erhalten IT-Teams sozusagen eine lastenorientierte Vorwarnung, im Gegensatz zu einem rollierenden Kubernetes Upgrade oder der Kubernetes-Implementierungsstrategie, die eine fallzahlenbasierte Vorwarnung gibt und dann auf eine Lastenverteilung über die unterschiedlichen Instanzen hinweg vertraut, um den Traffic aufzuteilen.

Der Traffic zwischen den Instanzen eines Microservices wird bei IP-Table Programmierung standardmäßig über die K8s Kube-Proxy-Controller verteilt. Der Einsatz des OpenContrail vRouters bietet einen kleinen Leistungs- und Skalierungsvorteil, da er sein eigenes ECMP Load Balancing und Network Adress Translation (NAT) nutzt, anstatt die IP-Tabellen des Kernels.

Service-Meshes handhaben diese Art von Load Balancing ebenso. Sie unterstützen eine Reihe weiterer Funktionen, sowohl im Hinblick auf Load-Balancing-Konzepte wie EWMA als auch in Fällen, in denen eine Instanz aus dem Load-Balancing-Pool entfernt wird – beispielsweise, wenn sie zu langsam ist.

Lesen Sie auch: Grundkurs Docker: Eine praktische Einführung in die Welt der Container

Service-Meshes können natürlich auch Load Balancing für eingehendes HTTP-Frontending handhaben. Linkerd und Istio integrieren sich mit K8S Ingress als Eingangscontroller. Im Gegensatz zu den meisten SDNs bietet OpenContrail eine Lösung, die auf haproxy basiert, einem Open Source TCP Proxy-Projekt. Ein Unterschied ist allerdings, dass OpenContrail momentan SSL/TLS noch nicht unterstützt. Es gibt aber Alternativen, die sich in K8s integrieren lassen. Dazu gehört z.B. Nginx für reines Software-Defined Load Balancing.

3. Reliablity Engineering

SRE und eine kontinuierliche Reaktion sind unter dem DevOps-Dach beheimatet. In diesem Segment spielen Service-Meshes ihre Stärke aus: Sie sind anwendungsspezifisch entwickelt und treiben hier die Zuverlässigkeit voran. Um die Leistung zu optimieren, unterstützen EWMA und ähnlich fortschrittliche Lastenausgleichsrichtlinien dabei, langsame Vorgänge zu vermeiden oder auszuschließen und so die End-Latenz zu verbessern. Envoy und Linkerd sind jedoch letztlich TCP-Proxies – und das Packen sowie Entpacken eines TCP-Streams erscheint der Netzwerk-Welt als extrem langsam. Mit den heutigen Prozessoren sind Envoy und Linkerd zwar sicherlich zwei der schnellsten TCP-Proxies auf dem Markt, es gibt aber immer IT-Manager, die vor der Einführung zusätzlicher Latenz zurückschrecken. Service-Meshes erhöhen zwar die Latenzzeiten durch die TCP-Proxy-Funktion, gleichzeitig reduzieren sie sie aber auch durch erhöhte Intelligenz.

Der Konsens scheint zu sein, dass Service-Meshes mehr Probleme lösen als sie erzeugen. Doch für welchen Fall eignen sie sich? Die Antwort ist: Es kommt darauf an. Wie bei DPI-basierten Firewalls kann diese Art von Traffic-verarbeitenden Applikationen eine niedrige Latenz und einen hohen Durchsatz mit einer bestimmten Bandbreite an Funktionen oder Last haben. Allerdings kann die Leistung massiv variieren und einbrechen, in Abhängigkeit von Feature-Aktivierung und Lastprofil. Es ist zwar kein fairer Vergleich, aber die nicht zustandsabhängige Verarbeitung, die ein SDN-Forwarding-Agent durchführt, ist immer schneller als solche Proxies. Dies gilt besonders, wenn intelligente NIC-Anbieter den vRouter direkt in die Hardware integrieren, wie es bei OpenContrail der Fall ist.

Sicherheit ist ein weiterer Bereich, dem in Bezug auf Zuverlässigkeit mehr Aufmerksamkeit gebührt. Sobald die Sprache auf TCP-Proxies kommt, sollten IT-Teams über Denial-of-Service-Attacken (DoS) nachdenken, denn es wird eine Vielzahl von Zustandsdaten generiert, um jede Sitzung zu verfolgen. Service-Meshes lösen das durch TLS; Linkerd unterstützt dies, aber Istio vereinfacht es dank des Istio Auth Controllers für das Schlüsselmanagement noch weiter. Das ist ein wichtiger Schritt, um nicht nur den Traffic über das Wire zu sichern (was SDNs über IPsec erreichen könnten), sondern für jeden Microservice eine starke identitätsbasierte AAA (Authentification, Authorization, Accounting) zu bieten. Diese Proxies sind in der Lage, das Wire-Protokoll beliebig zu verändern – egal, was von der Applikation initiiert wurde. Eine http-Anfrage lässt sich also innerhalb des TLS als HTTP2 über das Wire senden.

Der Leitungsausfall ist ein weiteres zu adressierendes Thema. Bei einer SDN-Lösung gibt es keine Möglichkeit, dies ohne einen Vielzahl von Analysen und Informationen zur Anwendungsverfolgung zu interpretieren und diese in die SDN-Anwendungsprogrammier-Schnittstelle einzufüttern. Selbst wenn das nur theoretisch möglich ist, bieten Service-Meshes dies bereits heute als integriertes Feature an, um Ausfälle mit möglichst geringem Eindruck zu bewältigen.

4. Testen und Fehlerbehebung

Da es sich um ein wichtiges Thema handelt, das aber nicht immer einen Vergleich von Funktionen zulässt, behandeln wir im Folgenden einige wichtige Punkte bzgl. Testen und Fehlerbehebung. Service-Meshes bieten einen Anwendungs-RPC-orientierten Einblick in die Interkommunikation im Microservice-Mesh. Diese Information kann für das Monitoring und die Betriebsvisibilität sowie während des Debugging extrem nützlich sein, um den Kommunikationsweg über eine Applikation hinweg zu verfolgen.

Linkerd integriert sich mit Zipkin für das Tracing und anderen Werkzeuge für Metriken. Dies eignet sich für Anwendungen, die in verschiedener Sprache geschrieben sind und unterscheidet sich damit von einigen sprachspezifischen Tracing-Bibliotheken.

Lesen Sie auch:

Service-Meshes bieten außerdem ein Routing pro Anfrage, das auf HTTP-Headern basiert, die sich für Tests beeinflussen lassen. Istio verfügt außerdem über eine Fehlereinstreuung und simuliert so Fehler innerhalb der Anwendung. Die Lösungen auf der SDN-Seite unterscheiden sich hier. OpenContrail hat mittlerweile einen relativ hohen Reifegrad im Vergleich zu anderen Wahlmöglichkeiten bei CNI-Anbietern erreicht. OpenContrail verfügt über ein Paketerfassungsprogramm und Sniffer wie Wireshark on demand. Die umfangreichen Analytics-Engines und Visibilitäts-Tools zeichnen Datenflussinformationen und andere Traffic-Statistiken auf. Über Debugging (auf Netzwerk-Ebene) hinaus gibt es eine Reihe von Security-Anwendungen, die ACL-Deny-Protokolle überprüfen.

OpenContrail stellt den kompletten Weg des Netzwerkverkehrs dar, wenn es auf einem physischen Netzwerk und nicht in der Cloud läuft. Dies kann potenziell beim Debugging helfen, aber die Informationen beziehen sich eher indirekt auf die Anwendungen und eignen sich wahrscheinlich besser für NetOps.

Legacy und andere Verzahnungen

Service Meshes sind in vielerlei Art und Weise hervorragend, aber es gibt einen Haken, der zu beachten ist: IT-Teams müssen im Kopf behalten, wie sie Microservices blockieren können, damit diese sich nicht mit den Legacy-Services oder anderen Services ohne Proxy verknüpfen können. Ob ein Status in S3 abgespeichert wird oder ein Cloud-Service abgefragt wird, ist eine externe Entscheidung. Das gleiche gilt auch für Legacy-Anwendungen wie eine Oracle-Datenbank oder für einen RPC oder anderen Microservice (beispielsweise in einer virtuellen Maschine anstatt in einem Container). Wenn der Microservice Non-TCP-Verkehr bearbeiten soll, wird dieser ebenfalls nicht über das Service-Mesh gehandhabt (zum Beispiel: DNS ist UDP-Traffic, Ping ist ICMP).

Im Fall von Istio lässt sich die Egress-Konnektivität mit einem Service-Alias herstellen. Dies könnte Veränderungen an der Applikation erfordern, ein direkter Pass-Thru ist die einfachere Option. Es gibt außerdem eine Vielzahl von TCP-Traffic-Varianten, die weder http sind, noch von übergeordneten Protokollen direkt unterstützt werden, die auf http aufsetzen. Gängige Beispiele sind ssh und Mail-Protokolle. Es stellt sich außerdem die Frage, wie Service-Meshes vielfache IPs und verschiedene Netzwerk-Schnittstellen pro Pod handhaben, sobald die Container-Network-Schnittstelle (CNI) dies erlaubt.

Zwischen den Applikationen gibt es in jedem Netzwerk Kommunikation, die nicht komplett in das Mesh passt. In diesen Fällen muss nicht nur geplant werden, welche Kommunikation erlaubt ist, sondern auch, wie ihre Absicherunge aussieht. Dies lässt sich zum Beispiel mit einer zugrunde liegenden SDN-Lösung wie OpenContrail erreichen, die sich von Kubernetes über OpenStack und VMWare bis hin zur Hardware erstreckt.

Fazit: Service-Meshes sind nur teilweise die nächste SDN-Generation

Zurück zur ursprünglichen Frage: Sind Service-Meshes die nächste Generation von SDN? Das sind sie nur teilweise: Service-Meshes bieten viele der Vorteile von SDN. Sie ermöglichen eine Mikro-Segmentierung und Sicherheit für Remote Procedure Call (RPC) zwischen Microservices – und zwar mit verbesserter TLS-basierter Security- und Identitätszuweisung für jeden einzelnen Microservice. Service-Meshes verfügen über modernes, anwendungsspezifisches Load Balancing und über Fehlerbehebung. Ohne Applikationsanalyse und Code Refactoring ist dies sonst nur schwer realisierbar.

Allerdings ersetzen Service-Meshes weder heute noch in daher Zukunft zwangsläufig SDN. Sie setzen auf der Container-Network-Schnittstelle und der Container-Vernetzung auf. Da sie über Software-Defined Networks laufen, benötigen sie immer noch eine solide Basis. Die meisten IT-Teams fordern außerdem mehrere Sicherheitsschichten, die Netzwerke isolieren und somit schützen, wenn sie eine Mikro-Segmentierung und Mandantenfähigkeit erhalten. Diese sind integraler Bestandteil von SDN-Lösungen und beeinträchtigen die Leistungsfähigkeit nicht.

Software-Defined Networks vernetzen darüber hinaus über Cluster, Stacks und Runtime-Code außerhalb von Containern. Damit erfüllen sie selbst die Wünsche von solchen IT-Teams, die möglichst niedrige Latenzzeiten verlangen. Auf jeden Fall bieten Service-Meshes eine Reihe von Vorteilen über ihren Netzwerk- und Security-Mehrwert hinaus. Sie werden in naher Zukunft in beinahe jede(s) Microservice-Architektur und -Stack integriert sein.

Geschrieben von
Wolfgang Kirchberger
Wolfgang Kirchberger
Wolfgang Kirchberger ist Systems Engineering Director DACH Region bei Juniper Networks.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: