Service-Mesh: Istio 1.10 soll besser in größeren Clustern arbeiten

Eine durch Discovery Selectors gezieltere Auswahl zu überwachender Kubernetes-Ressourcen soll helfen, Skalierungsengpässe zu vermeiden.

In Pocket speichern vorlesen Druckansicht

(Bild: PopTika/Shutterstock)

Lesezeit: 2 Min.

Das Istio-Team hat das zweite Release der Service-Mesh-Plattform im Jahr 2021 veröffentlicht. Mit Istio 1.10 sollen Entwicklerinnen und Entwickler auch in größeren Kubernetes-Cluster-Umgebungen etwaige Skalierungsengpässe umschiffen können, die sich bei einer zu großen Zahl der durch das Service-Mesh zu überwachenden Ressourcen ergeben können.

Dafür stehen in Istio nun Discovery Selectors zur Verfügung, mit denen sich gezielt jene Ressource im Cluster bündeln lassen, die das Service-Mesh überwachen soll. Vergleichbar zu Istios Sidecar-API-Ressource begrenzen Discovery Selectors die Konfigurationssätze, die das Service-Mesh von Kubernetes empfängt und verarbeiten muss. So lassen sich beispielsweise in umfangreichen Clustern mit häufigen Konfigurationsänderungen, diejenigen aus weniger oder nicht relevanten Namespaces ausblenden – wie beispielsweise Spark Jobs. Weitere Details zu den Konfigurationsoptionen der Discovery Selectors fasst ein separater Blogbeitrag zusammen.

Das sichere Bereitstellen mehrerer Control Planes unterschiedlicher Revisionen beherrscht Istio bereits seit Version 1.6. Änderungen der Revisionen erforderten bisher jedoch einen hohen Aufwand beim Neumarkieren von Namespaces, weil ein Label direkt einer bestimmten Istio-Kontrollebene zugeordnet war. Dank Revision Tags lassen sich ab Istio 1.10 nun Tags wie canary und prod erstellen und den Namespaces zuordnen, um sie als Revisionen zu kennzeichnen. Anschließend lässt sich dann eine bestimmte Istiod-Revision mit diesem Tag verknüpfen.

Weitere Neuerungen in Istio 1.10 betreffen das Pod Networking. Envoy schickt Traffic an Applikationen künftig standardmäßig an eth0 statt an lo. Da einzelne Anwendungen jedoch spezifisch nur auf eine der beiden Schnittstellen ausgerichtet sein können, sollten insbesondere Anwenderinnen und Anwender mit älteren Applikationen über istioctl experimental precheck prüfen, welche Pods auf Localhost lauschen, um etwaige Maßnahmen gemäß IST0143 ergreifen zu können.

Vor dem Update auf Istio 1.10 sollten Entwicklerinnen und Entwickler außerdem zwei Deprecations beachten: der Kubernetes-JWT-Support (values.global.jwtPolicy=first-party-jwt) gilt als unsicher und wird daher entfernt. Auch die Option values.global.arch gilt als veraltet und wird durch die Affinity-Einstellungen in der Kubernetes-Konfiguration ersetzt.

Alle weiteren Neuerungen im Service-Mesh fasst der Istio-Blog zusammen, Details zu sämtlichen Änderungen finden sich in den Releas Notes zu Istio 1.10.

(map)