Seite 2: Linkerd 2: Für Kubernetes neu aufgelegt

Inhaltsverzeichnis

Linkerd 1 von Buoyant war das erste Produkt, das ein Service-Mesh implementierte und somit den Begriff definiert hat. Als Technik-Stack haben die Erfinder Scala in Verbindung mit Netty und Finagle benutzt. Die nahe Verwandtschaft zum Twitter-Stack ist kein Zufall: Beide Buoyant-Gründer sind ehemalige Twitter-Mitarbeiter. Sie haben 2015 erkannt, dass der Twitter-Stack generell für verteilte Systeme einen großen Nutzen hat und Buoyant gegründet, um ein Service-Mesh zu bauen. Die Auswahl der JVM als Laufzeitumgebung für die Data Plane hat sich jedoch als ungeeignet herausgestellt: Wenn zu jeder Microservice-Instanz ein Service-Proxy hinzugefügt wird, sind die Latenz und Ressourcenanforderungen der JVM zu hoch.

Ein weiteres Problem von Linkerd 1 ist dessen Komplexität: Ähnlich wie Istio kann Linkerd 1 in verschiedenen Umgebungen zum Einsatz kommen und ist dementsprechend umfassend konfigurierbar. Um die Probleme von Linkerd 1 zu beheben, hat Buoyant ein neues Service-Mesh Produkt namens Linkerd 2 (ursprünglich Conduit) von Grund auf neu entwickelt. Wie Linkerd 1 ist auch die neue Version komplett unter der Apache-2.0-Lizenz verfügbar. Der Artikel bezieht sich, sofern nicht explizit angegeben, immer auf Version 2 von Linkerd.

Mehr Infos

Service-Meshes auf der Continuous Lifecycle und ContainerConf

Auf den von heise Developer, iX und dpunkt.verlag veranstalteten Konferenzen Continuous Lifecycle und ContainerConf ist das Konzept der Service-Meshes ein wichtiges Thema. Mehrere Vorträge und Workshops widmen sich unterschiedlichen Aspekten der Technik. Die Konferenzen finden vom 12. bis 15. November 2019 in Mannheim statt, Frühbucherrabatt gilt noch bis zum 21. September.

Das neue Linkerd nutzt Go für die Control Plane und Rust für die Data Plane und reduziert damit Ressourcenanforderungen und Latenzeinbußen gegenüber Linkerd 1 erheblich. Ziele sind unter anderem eine einfache Installation und ein komfortabler Betrieb. Version 2 hat sich dazu auf Kubernetes als Plattform beschränkt. Im Gegensatz zu Linkerd 1 setzt Linkerd 2 also eine spezifische Umgebung voraus, die es weniger flexibel, aber leichter zu pflegen machen.

Ähnlich wie bei Istio müssen Entwickler den Namespace oder den Pod mit bestimmten Annotationen markieren, damit eine Anwendung in das Service-Mesh aufgenommen wird. Die Service-Proxys werden dann automatisch in den jeweiligen Pod injiziert. Alternativ können Nutzer Kubernetes-Konfigurationsdateien per Skript manipulieren, bevor sie angewendet werden.

SMI: Eine gemeinsame API für Service-Mesh Features

Linkerd und Istio sind nicht die einzigen Service-Mesh-Implementierungen. Auch HashiCorp und Amazon Web Services haben eigene Service-Meshes entwickelt. Entstanden ist eine Vielzahl an Konzepten und APIs. Mittlerweile gibt es viele Tools, die auf Service-Meshes aufbauen:

• Flagger, zur Automatisierung von Canary Releasing und A/B-Testing,
• Squash, ein Debugger für laufende Microservice-Anwendungen und
• Kiali, ein Service-Mesh-Dashboard, das aktuell nur für Istio verfügbar ist.

Damit nicht jedes Service-Mesh derartige Tools entwickeln muss, haben Microsoft, HashiCorp, Buoyant und Solo.io gemeinsam eine API-Spezifikation für Service-Mesh Features entwickelt. Das im Mai 2019 auf der KubeCon vorgestellte Service-Mesh Interface (SMI) wird von Linkerd und Istio unterstützt, wenn auch nur zu einem kleinen Teil.