© Josef / 123RF.com

Mesh-Implementierungen für Container-Umgebungen gibt es mittlerweile etliche wie etwa Istio oder Linkerd. Traefik verspricht, Container-Netze nicht nur zuverlässig zu verwalten, sondern so, dass sie sich angenehm handhaben lassen.

Ganz gleich, wie sehr die Container-Apologeten der modernen IT es Admins auch einreden wollen: Natürlich sind virtualisierte Systeme auf Basis von Kubernetes und Konsorten deutlich komplexer als ihre altertümlichen Vorgänger. Das wird schon in dem Moment völlig klar, in dem man die Anzahl der Komponenten in einer konventionellen Umgebung mit jener in einer Kubernetes-Installation vergleicht.

Webserver-Setups folgen einer einfachen Struktur: Ein Load Balancer, eine Datenbank, jeweils in irgendeiner Weise redundant, dann etliche Applikationsserver, auf die die Load Balancer zeigen – fertig ist der Lack. Virtualisierte Container-Umgebungen auf Basis von Kubernetes und Co. enthalten diese Komponenten auch, haben zusätzlich aber Virtualisierungs- und Orchestrierungskomponenten im Gepäck.

Hinzu kommen Bauteile, wie sie die Cloud-ready-Architektur vorsieht, der viele virtualisierte Dienste heute folgen: Dutzende Fragmente und Kleinstdienste, die sich im Hintergrund irgendwie miteinander austauschen wollen, und zwar auch dann, wenn sie auf unterschiedlichen Knoten in weitverzweigten Server-Farmen laufen und per Software Defined Networking (SDN) kommunizieren müssen.

DevOps bekommt in solchen Umgebungen ebenfalls eine neue Bedeutung. Selbst wenn man die typische Trennung in spezialisierte Teams umsetzen wollte, die sich um Netz, Applikation und Betrieb kümmern – es wäre schlicht unmöglich. Zu verzahnt sind die einzelnen Ebenen miteinander und zu schwierig ist es heute, sie zu entflechten.

Deshalb hat sich eine Kategorie von Programmen etabliert, die es Admins wie Entwicklern erleichtern wollen, diese Komplexität zu schultern. Im Linux-Magazin waren solche Werkzeuge bereits mehrmals Thema: Der Service-Mesh Istio etwa baut zwischen den einzelnen Mikro-Komponenten eine dynamische Load-Balancer-Umgebung samt verkapseltem Traffic auf, die ad hoc SSL-Verschlüsselung und Endpunktüberwachung nachrüstet.

Auf dem Markt gibt es diverse Alternativen: Consul, ursprünglich ein reiner Algorithmus für Konsensfindung in verteilten Umgebungen, bietet mittlerweile ebenso Mesh-Funktionalität wie Linkerd (Abbildung 1). Dass es sich bei Mesh-Netzen also um einen Kuchen handelt, von dem viele Unternehmen ein (gern auch größeres) Stück abhaben wollen, liegt auf der Hand.

Abbildung 1: Mesh-Netzwerke wie hier Linkerd liegen im Trend. Quelle: Linkerd

Traefik will besser sein

In diesem Artikel kommt Traefik zum Einsatz, ein weiterer Vertreter der Proxy-Server-Kategorie mit Mesh-Hintergrund. Es geizt ähnlich wie die Konkurrenz nicht mit diversen Versprechen: Das Programm möchte die Arbeit in DevOps-Umgebungen einfach und angenehm gestalten, dem Thema gar “den Schrecken nehmen” und letztlich dafür sorgen, dass Admins, die eigentlich nicht Netzwerk-affin sind, sich gern mit dem Thema und angrenzenden Gebieten befassen. Das ist traditionell eher nicht der Fall: Viele Administratoren, die im klassischen Silo-Denken der IT der frühen Nuller-Jahre aufwuchsen, sehen in Netzwerken (und oft auch in Storage) Teufelszeug.

Dem wirkt Traefik entgegen: Es will SDN-Ansätze in Container-Umgebungen überflüssig machen, indem es sie durch einfache Technologie ersetzt. Traefik tritt dabei als Reverse Proxy und Load Balancer, aber auch als Mesh-Netzwerk auf. Wir stellen das gesamte Konstrukt auf den Prüfstand und untersuchen, für wen Traefik interessant sein könnte. Vorher ist es jedoch hilfreich, ein paar ganz grundlegende Fragen zu beantworten, vor allem zur Terminologie.

Begriffe klären

Traefik heißt zunächst die Firma, die sich um die kommerzielle Weiterentwicklung des Traefik-Proxys kümmert. Die Komponente, die heute Traefik Proxy [1] heißt, hieß allerdings nicht immer so. Anfangs war sie die einzige Komponente des Traefik-Projekts, sodass Projekt und Produkt beide einfach Traefik genannt wurden. Als man das Funktionsangebot dann um eine Mesh-Lösung nach dem Vorbild von Istio erweiterte, wurde aus Traefik Traefik Proxy, und die Mesh-Lösung nannte man Traefik Mesh [2].

Mittlerweile hat der Anbieter noch zwei weitere Produkte im Programm: Bei Traefik Pilot handelt es sich um ein grafisches Dashboard, das Verbindungen von Traefik Mesh und Traefik Proxy in einer Anwendung grafisch darstellt. Traefik Enterprise ist dagegen kein technisches Produkt im engeren Sinne, sondern eine Kombination aus den drei Software-Produkten mit zusätzlichen Features und Support. In diesem Artikel geht es bevorzugt um Traefik Proxy und Traefik Mesh, das Traefik-Dashboard kommt aber ebenfalls zur Sprache.

Wer glaubt, sich in Sachen Traefik-Begriffen nun auszukennen, hat allerdings nicht mit der Kreativität der Traefik-Entwickler gerechnet. Denn der Proxy, so die Traefik-Oberen, sei eigentlich viel mehr als ein reiner Proxy. Zwar wolle man das Produkt nicht umbenennen, faktisch sei Traefik aber eher ein Edge-Router, den man sowohl als Reverse Proxy als auch als Load Balancer betreiben kann. Was die Unterschiede zwischen einem Edge-Router, einem Reverse Proxy und einem Load Balancer sein sollen, lassen die Entwickler dabei höchstens anhand bunter Bildchen vermuten. Höchste Zeit also, der Sache auf den Grund zu gehen.

Traefik und Kubernetes

Die ursprüngliche Idee hinter Traefik (Abbildung 2) war eigentlich die Entwicklung eines Reverse-Proxy-Servers, der im Gespann mit Container-Orchestrierern wie Kubernetes besonders gut funktionieren sollte. Besonders gut meint im konkreten Fall, dass der Proxy-Server auf der Kubernetes-Ebene ein First Class Citizen sein sollte, eine Ressource also, die sich über die gewohnten Kubernetes-APIs bedienen lässt.

Abbildung 2: Traefik fungiert als Reverse Proxy und Load Balancer mit einer Reihe zusätzlicher Features wie Let’s-Encrypt-Integration. Quelle: Traefik

Heute ist das selbstverständlich. In den frühen Kubernetes-Jahren war allerdings auf der einen Seite die Kubernetes-API nicht so funktional wie heute, auf der anderen war das gesamte Ökosystem rund um Kubernetes mehr schlecht als recht ausgebaut. Oft behalfen sich Admins deshalb mit Bastellösungen: Wer einen HA-Proxy brauchte, baute sich etwa einen Pod mit HA-Proxy-Container, der per Automation die passende Konfiguration eingeflüstert bekam. Das funktionierte in vielen Fällen, blieb vor dem Hintergrund der Steuerbarkeit allerdings unbefriedigend.

Die Traefik-Entwickler verfolgten bei ihrer Arbeit deshalb von Anfang an einen anderen Ansatz. Traefik sollte als native Kubernetes-Ressource daherkommen und wie die anderen Ressourcen in Kubernetes auch über dessen APIs verwaltbar sein. Noch vor der Veröffentlichung einer formalen Version 1.0 erreichten die Entwickler dieses Ziel auch, und Traefik war einer der ersten Reverse Proxies am Markt mit diesem Feature-Set.

Traefik als Reverse Proxy

Den Begriff Reverse Proxy kennen Administratoren konventioneller Setups vermutlich aus dem Nginx-Kontext. Oft dient Nginx im Reverse-Proxy-Modus als Krücke: Wenn ein eigentlich internes System kein Standbein im Internet haben darf, bietet ein Reverse Proxy eine gute Möglichkeit, es von außen trotzdem erreichbar zu machen. Der Reverse Proxy kann etwa in einer DMZ stehen und eine öffentliche IP-Adresse samt offenem Port ins Internet exponieren. Verbindungen zu dieser IP leitet er an den eigentlichen Server im Hintergrund weiter.

Er bietet verschiedene Möglichkeiten, die ohne Reverse Proxy nicht zur Verfügung stünden: Per Nftables kann er den Zugriff etwa auf bestimmte Hosts beschränken. Regelmäßig kommen Reverse Proxies auch als SSL-Terminator zum Einsatz: Sie exponieren zur Außenwelt hin dann eine HTTPS-Schnittstelle, ohne mit ihrem Backend zwingend SSL reden zu müssen. Dasselbe gilt für die Möglichkeit, den Zugriff auf eine Web-Ressource per HTTP-Authentifizierung zu regulieren. Beide Features kommen gern bei Webanwendungen zum Einsatz, die diese Funktionen selbst nicht bieten.

Traefik als Load Balancer

Gedanklich ist es vom Reverse Proxy zum Load Balancer nicht mehr weit. Letzterer unterscheidet sich vom Ersteren maßgeblich dadurch, dass er eingehende Requests auf mehr als ein Backend verteilen kann und entsprechend auch Logik an Bord hat, um das sinnvoll zu tun. Dazu gehören verschiedene Weiterleitungsmodi und die Algorithmen, anhand derer die Weiterleitung geschieht.

Ursprünglich ging Traefik als Reverse Proxy an den Start; dass das Tool sich irgendwann zum Load Balancer weiterentwickeln würde, war insofern absehbar. Mittlerweile ist das längst erfolgt, und Traefik Proxy lässt sich nicht nur als Proxy mit einem Backend betreiben, sondern auch als Load Balancer mit mehreren Zielsystemen.

Mehrwert im Kubernetes-Kontext

Der bis hierhin beschriebene Funktionsumfang von Traefik Proxy entspricht dem eines klassischen Reverse Proxys und Load Balancers: Auf der einen Seite nimmt der Dienst Verbindungen an, um sie auf der anderen Seite an das konfigurierte Backend weiterzuleiten. Das funktioniert bei Traefik protokollagnostisch auf der OSI-Ebene 4, oder spezifisch für HTTP/HTTPS auf Layer 7.

Das ursprüngliche Killer-Feature von Traefik war dabei stets die tiefe Integration in Kubernetes: Wer seinen Workload in Kubernetes betrieb, sollte sich um die Proxy-Konfiguration keine Sorgen machen müssen; sie würde als Teil der Pod-Definitionen aus Kubernetes einfach mitkommen. Zusätzlich haben die Traefik-Entwickler ihrer Applikation mehrere Funktionen spendiert, die vor allem im Kubernetes-Kontext viel Sinn ergeben.

Dazu gehört, dass Traefik als API-Gateway fungieren kann. Der Begriff ist nicht näher definiert, doch gibt es ein paar grundlegende Funktionen, die Admins von einem solchen API-Gateway üblicherweise erwarten. Im Kern handelt es sich bei einem API-Gateway stets um einen Load Balancer, der allerdings protocol-aware ist (daher OSI-Layer 7). Er versteht den vorbeifließenden Datenverkehr nicht nur, sondern greift auf Wunsch des Admins auch in diesen ein. Einige Beispiele dafür hat der Artikel schon geliefert, etwa vorgeschaltete Authentifizierung und Transportverschlüsselung per SSL.

Hinzu kommt Traefiks Eigenschaft, als Ingress-Controller in Kubernetes zu funktionieren. Ingress-Controller sind in Kubernetes eine spezielle Vorbereitung in der API für externe Komponenten, die mit eingehendem Datenverkehr hantieren sollen. Indem der Admin einen Dienst in seinen Pod-Definitionen zum Ingress-Controller macht, weist er Kubernetes an, spezielle Arten von Traffic oder den gesamten Verkehr durch diesen Controller zu schleusen. Auf diese Weise ist die Eigenschaft von Traefik als First Class Citizen implementiert, auf die der Artikel zuvor schon näher eingegangen ist.

Zertifikatsmanagement

Darüber hinaus implementiert Traefik Proxy eine Funktion, die für viele Admins als eine Art Killer-Feature gelten dürfte: Es hat einen ACME-Client und beherrscht daher die Kommunikation mit Diensten wie Googles Let’s Encrypt.

Das Handling von Zertifikaten ist bei Admins in aller Regel sehr unbeliebt, denn der Betrieb einer eigenen Zertifikatsverwaltung ist mühsam und aufwendig. Selbst das Anlegen eines Certificate Signing Requests (CSR) führt regelmäßig dazu, dass Admins sich in die Untiefen der Kommandozeilenparameter von OpenSSL begeben, was selten die Laune hebt. Das automatische Anfragen nach SSL-Zertifikaten via Let’s Encrypt entbindet den Admin nicht nur von dieser lästigen Arbeit, sondern sorgt auch dafür, dass ausgelaufene Zertifikate als Problemquelle wegfallen. Traefik Proxy spricht bei Bedarf mit Let’s Encrypt und holt sich für öffentliche Endpunkte von Diensten in Pods offizielle Zertifikate.

Ein robuster Reverse Proxy und Load Balancer, der sich aus Kubernetes heraus steuern lässt, darf per se als wertvolles Asset gelten. Doch ist die Welt in den vergangenen Jahren komplexer geworden, besonders im Container-Kontext, und hier spielen Microservices eine entscheidende Rolle dafür, dass reine Reverse Proxys und Load Balancer heute nicht mehr ausreichen. Microservices machen eine Applikation auf der einen Seite hochflexibel und auf der anderen schwierig zu betreiben. Je nach anliegender Last und eigener Konfiguration startet Kubernetes beliebig viele Instanzen bestimmter Dienste oder lässt diese ad hoc im Orkus verschwinden, etwa dann, wenn gerade nicht viel Last anliegt und die Ressourcen anderen Aufgaben dienen sollen.

Das macht es indes enorm schwierig, den Überblick über sämtliche Pfade zur Kommunikation zwischen den einzelnen Instanzen zu bewahren oder die Pfade zu konfigurieren – eigentlich ist das sogar unmöglich. Händisch alle Instanzen von Dienst A so zu programmieren, dass er mit allen bekannten Instanzen von Host B redet, lässt sich in der Praxis mit vertretbarem Aufwand nicht realisieren – einmal davon abgesehen, dass die meisten Komponenten von Mikroarchitektur-Anwendungen heute per REST oder gRPC miteinander kommunizieren, die im Kern auf HTTP fußen oder es zumindest stark nutzen. HTTP sieht es jedoch gar nicht vor, für eine Verbindung mehrere mögliche Ziele anzugeben.

Meshes als Makler

Langer Rede kurzer Sinn: Auf der Applikationsebene lässt sich die Kommunikation zwischen den verschiedenen Komponenten einer Applikation kaum sinnvoll implementieren. Im Fahrwasser von Kubernetes und Konsorten erfreuen sich deshalb seit einiger Zeit auch Mesh-Lösungen großer Beliebtheit. Sie schalten sich zwischen die Instanzen aller Dienste einer Microservices-Applikation und fungieren als eine Art Makler: Sie registrieren ausscheidende und neu hinzukommende Instanzen der einzelnen Dienste automatisch, leiten neue Verbindungen darauf weiter und etablieren so ein durchgängiges Kommunikationsnetzwerk.

Um die Marktentwicklung nicht zu verschlafen, erweiterten die Traefik-Entwickler die Funktionalität ihrer Lösung und schnürten ein Produkt namens Traefik Mesh (Abbildung 3). Im Zentrum von Traefik Mesh steht noch immer Traefik Proxy, doch das technische Fundament dieser Lösung unterscheidet sich fundamental vom Ansatz, der dem einen oder anderen Admin vielleicht von Istio und Co. her bekannt ist.

Abbildung 3: Traefik Mesh nutzt nicht das Sidecar-Prinzip, sondern betreibt pro Host nur einen Proxy-Server. Das spart auf dem Host Ressourcen. Quelle: Traefik

Ressourcenintensive Sidecars

Die Architektur von Lösungen wie Istio heißt oft auch Sidecar-Architektur, weil sie jedem Dienst in einer Umgebung einen Proxy-Server zur Seite stellt. Das geschieht unmittelbar im Pod, bedingt also, dass die Proxy-Komponente Teil der Pod-Definition ist. Um etwa Istio so einzusetzen, muss der Admin oder Entwickler Istio auf der Kubernetes-Ebene zum Bestandteil eines Pods machen.

In einem solchen Konstrukt reden die diversen Instanzen der Microservices gar nicht mehr unmittelbar miteinander: Jede Instanz hat stattdessen ihren eigenen Proxy, der eingehende Verbindungen dynamisch an die eigene oder eine andere Instanz weiterleiten kann. Traefik nennt dieses Design “invasiv”, eben weil es bedingt, dass auf der Pod-Ebene jede Definition die für Istio nötigen Komponenten enthält.

Dieser Ansatz hat zweifelsohne technische Vorteile, etwa umfassende mTLS-Verschlüsselung zwischen allen Instanzen und allen Apps. Dennoch stößt man bei Traefik noch auf ein anderes Problem, den Ressourcenverbrauch der Proxy-Server, die als Sidecar Teil der Pods sind. Logisch: 20 Sidecar-Instanzen des Proxies bei 20 Instanzen verschiedener Apps in einer Microservice-Umgebung kommen naturgemäß mit deutlichem Overhead daher.

Ohne Beiwagen

Das Traefik-Mesh funktioniert anders, was auch seiner eigenen Geschichte geschuldet ist. Gerade weil der Proxy ursprünglich als erster Dienst mit nativer Kubernetes-Unterstützung vorhanden war, lag es auf der Hand, ihn zum Mesh aufzubohren. Wer Traefik als Mesh nutzen möchte, rollt in Kubernetes deshalb nicht ein Sidecar pro Pod mit relevanter Applikation aus, sondern einen Kubernetes-Proxy pro physischem Host. Letztlich hat der Admin beim Deployment der Container auf die Anzahl pro Host ohnehin keinen direkten Einfluss, wenn er den Proxy als native Kubernetes-Ressource ausrollt.

In der Praxis führt das zu einer geänderten Kommunikationsmatrix, sobald der Entwickler einer Anwendung sie für die Nutzung des Proxy-Servers konfiguriert. Jede Applikation kommuniziert dann durch den pro Host vorhandenen, zentralen Traefik-Proxy mit anderen Diensten in anderen Pods und auf anderen Hosts. Der durch mehrere Proxy-Server pro Server bedingte Overhead entfällt ebenso wie der erhöhte Konfigurationsaufwand durch geänderte Pod-Definitionen. Praktisch gerade für Debugging-Zwecke ist zudem, dass die ursprünglichen Kommunikationspfade zu den einzelnen Apps in den diversen Pods erhalten bleiben. Apps und Anwender entscheiden im Wesentlichen durch die Adresse, durch die sie einen Dienst kontaktieren, ob die Kommunikation via Traefik-Proxy erfolgt.

Bei Traefik fällt an vielen Stellen die Liebe zum Detail auf, die die Entwickler walten lassen. Admins und Entwickler fluchen etwa regelmäßig, weil es schwierig ist, in dynamischen, verwobenen Mesh-Umgebungen Fehler zu suchen oder gar zu finden. Am Markt hat sich mittlerweile deshalb eine eigene Gattung von Werkzeugen etabliert, die diese Aufgabe erleichtern: sogenannte Tracing Tools wie Jaeger.

Damit Jaeger allerdings als Spürhund überhaupt arbeiten kann, braucht er eine Kommunikationsschnittstelle, um sich in den laufenden Austausch zwischen allen Komponenten einzuklinken. Traefik Proxy bietet eine solche Schnittstelle und erleichtert Entwicklern das Debugging damit erheblich. Zusätzlich lässt sich Traefik Proxy unkompliziert in eine Reihe von Monitoring-Anwendungen integrieren, deren Fokus auf moderner Infrastruktur liegt. Schnittstellen für Prometheus (Abbildung 4) oder InfluxDB sind ebenfalls ab Werk vorhanden. Schon für die Open-Source-Variante von Traefik ergibt sich dadurch eine umfassende Überwachbarkeit mitsamt dem guten Gefühl für den Admin, zu wissen, was in der eigenen Umgebung vor sich geht.

Abbildung 4: Traefik Proxy bietet Schnittstellen für Metrikdaten zu diversen Lösungen wie Prometheus oder InfluxDB, wo die Daten sich per Grafana dann auch grafisch darstellen lassen. Quelle: Nick Babcock

Darüber hinaus profitieren Mesh-Umgebungen auch von den anderen in Traefik Proxy ohnehin vorhandenen Features. Dazu gehören das dynamische Erkennen neuer Instanzen einzelner Dienste sowie von Instanzen, die zwischenzeitlich weggefallen sind, sowie das konfigurierbare Rate Limiting, um einzelne Instanzen einzelner Dienste nicht über Gebühr zu beanspruchen.

Traefik Pilot

Traefik entpuppt sich als Proxy, der sich auch im Mesh-Kontext nutzen lässt, wobei die vielseitige Lösung die Komplexität etwa gegenüber Istio deutlich reduziert. Trotzdem legen die Entwickler großen Wert darauf, das Konstrukt für den Admin durchschaubar und verständlich zu halten. Auch ohne Zusatzkomponenten wie Jaeger sollen Admins und Entwickler über den Zustand von Traefik stets informiert sein.

Dazu schicken die Entwickler Traefik Pilot (Abbildung 5) ins Rennen, im Kern eine GUI zur Überwachung und zum Monitoring von Traefik. Sie nutzt dessen Interfaces zur Datengewinnung, zieht aus den gewonnen Metrikdaten Monitoring- sowie Trending-Informationen, und stellt diese optisch aufbereitet dar. Obendrein lassen sich Traefik-Instanzen aus Pilot heraus unmittelbar steuern, etwa zur Nutzung von Traefiks Plugin-Schnittstelle. Sie erlaubt es, Traefik um zusätzliche Features zu erweitern, die seitens des Herstellers nicht zum Lieferumfang zählen.

Abbildung 5: Traefik Pilot ist die Überwachungslösung für Traefik, die der Hersteller selbst ins Rennen schickt. Quelle: Traefik

Traefik Enterprise

Zu guter Letzt sei noch auf die kommerzielle Variante von Traefik hingewiesen. Traefik Enterprise richtet sich an Unternehmen, die Traefik im großen Stile einsetzen wollen und denen das Feature-Set der Open-Source-Variante dabei nicht genügt.

Für Entwickler gerät das stets zum Ritt auf der Kanonenkugel: Einerseits legen viele Firmen aus dem Container-Umfeld Wert darauf, Open-Source-Software anzubieten und zur Open-Source-Community zu gehören. Andererseits etablieren sich im Markt auch immer mehr Lösungen, bei denen selbst sehr grundlegende Funktionen nur in der Bezahlvariante zu haben sind. Traefik gelingt es, hier einen sinnvollen Mittelweg zu finden. Traefik Proxy selbst sowie die darauf basierende Mesh-Lösung sind Open-Source-Software und lassen sich ohne Überweisung an Traefik nutzen. Anders sieht es da bei Traefik Pilot aus, das es nur gegen Geld und auch nicht als Open-Source-Anwendung gibt.

Bei manchen Features, die Traefik der Enterprise-Variante exklusiv vorbehält, lässt sich zudem argumentieren, dass sie für den Regelbetrieb im Jahr 2021 eigentlich nötig sind. Wer Traefik etwa an irgendeine Form externen Managements für Identitätsdaten ankoppeln möchte, etwa an LDAP oder OAuth 2, der braucht zwingend die Bezahlversion der Software. Auch die ab Werk eingebauten Funktionen für Backup und Restore sowie eine Kompatibilitätsschnittstelle zu konventionellen Umgebungen bleiben der Kommerzvariante vorbehalten. Zumindest das Thema Backup lässt sich aber auch anders erschlagen.

In Summe fällt Traefik damit nach gängiger Definition noch nicht in die Kategorie Fake Open Source. Der Hersteller folgt jedoch der Unart, Ross und Reiter in Sachen Preis auf seiner Website nicht klar zu nennen. Was Traefik von Enterprise-Kunden verlangt, richtet sich laut Herstelleraussage nach der Proxy-Anzahl und dem Grad der kritischen Infrastruktur – also nach der Frage, wie subjektiv wichtig dem Admin der jeweilige Proxy ist.

Fazit

Reverse Proxies und Load Balancer stehen in Container-Umgebungen völlig anderen Herausforderungen gegenüber als in konventionellen Setups. Hier spielt auf der einen Seite die Dynamik eine große Rolle, mit der bestehende Dienste verschwinden und neue Instanzen von Anwendungen aus dem Boden schießen. Andererseits ist von großer Bedeutung, dass die Verbindungen zwischen all diesen Instanzen viel flexibler ausfallen, als es in früheren Umgebungen der Fall war. Der Container-Zirkus hat deshalb gar eine eigene Software-Gattung erfunden, nämlich die Mesh-Netze für Kubernetes.

Traefik entpuppt sich dabei als spannende Alternative zu Istio, Linkerd und Konsorten, weil es mit technisch deutlich weniger Aufwand und erheblich niedrigerem Overhead sehr ähnliche Effekte erzielt. Zwar fallen dabei einige wenige Features unter den Tisch, doch für den Admin durchschnittlicher Container-Lösungen dürfte Traefik einen Blick wert sein.

In der Open-Source-Version genügt das Feature-Set der Lösung durchaus für alltägliche Aufgaben, auch wenn man sich als Entwickler oder Administrator sicher das eine oder andere Feature der Enterprise-Edition wünschen würde. Bei den wichtigsten Punkten jedoch holt Traefik die volle Punktzahl: Traefik-Ressourcen lassen sich aus Kubernetes heraus problemlos verwalten und sind echte First Class Citizens. Wer Istio und das Prinzip des Sidecars also nicht mag, findet in Traefik vermutlich eine gute und gut funktionierende Alternative. (jcb/jlu)