Service-Mesh: Istio 1.2 soll den Releasezyklus stabilisieren

Nachdem Istios Sprung von Version 1.0 auf 1.1 neun Monate gedauert hat, liegen zwischen 1.1 und 1.2 nun knapp drei Monate. Das soll zukünftig so bleiben.

In Pocket speichern vorlesen Druckansicht
Service-Mesh: Istio 1.2 soll den Releasezyklus stabilisieren

Monika1607, Pixabay

Lesezeit: 2 Min.
Von
  • Björn Bohn

Das Service-Mesh Istio ist in Version 1.2 erschienen. Der Fokus liegt dabei wohl vor allem auf einer besseren Stabilität der Test-, Build- und Release-Mechanismen, die das Istio-Team in der Vorgängerversion umgekrempelt hatte. Damit sollen neue Istio-Veröffentlichungen in Zukunft regelmäßiger vom Stapel gehen, als das bei der neunmonatigen Wartezeit zwischen Versionen 1.0 und 1.1 der Fall war. Die Entwickler des Service-Mesh haben sich dafür in vier neue Gruppen organisiert. Einige neue Features bietet das Release dennoch.

Im Blogbeitrag zum Release erklären die Köpfe hinter dem Service-Mesh zunächst die ausgedehnte Stille zwischen Istios erster Hauptversion im August 2018 und dem ersten Punkt-Release vergangenen März. Es seien größere Arbeiten am Testprozess und der Infrastruktur notwendig gewesen. Um deren Zuverlässigkeit weiter voranzutreiben, hat sich die Istio-Community in vier Teams mit unterschiedlichen Ausrichtungen organisiert: GitHub WorkFlow, Source-Organisation, Testing-Methodologie sowie Build- und Release-Automatisierung. Das soll für zeitige Release und eine bessere Qualität sorgen.

Damit Anwender neue Features schneller ausprobieren können, landete der Großteil der Neuerungen bereits in den Patch-Releases der Reihe Istio 1.1.x. Nun sind sie aber offiziell Teil der neuen Istio-Version. Als Ergebnis der Arbeit einer Usability-Gruppe können Istio-Nutzer nun die Log-Level für Control und Data Plane global setzen. Zusätzlich dient der Befehl istioctl nun dazu zu überprüfen, ob eine vorhandene Installation der Container-Orchestrierung Kubernetes die Anforderungen für Istio erfüllt. Die neue Annotation traffic.sidecar.istio.io/includeInboundPorts soll hingegen dem Inhaber eines Service das Deklarieren von containerPort in der Deployment-YAML-Datei ersparen.

Eine vollständige Liste der Neuerungen bieten die Release Notes. Sie umfassen auch den Statuswechsel einiger Features von Beta zu stabil und neu hinzugekommene experimentelle Neuerungen.

Siehe dazu auf heise Developer: