Version 1.18 ist die erste von vier geplanten Veröffentlichungen für das Jahr 2020. Von den 38 angekündigten Neuerungen gehen 15 in die Stable Version, 11 gehen in die Betaphase über und 12 werden als Alpha-Releases veröffentlicht.
Neuer „kubectl debug“-Command
Unter den Alpha-Neuerungen ist zum Beispiel ein Command namens kubectl debug
, der es ermöglichen soll, Pods innerhalb eines Kubernetes-Clusters zu debuggen. Der Command versetzt Entwicklerteams in die Lage, einen temporären Container aufzusetzen, der es ermöglicht, einen Pod auch während des Troubleshootings auftretender Probleme auszuführen.
CSI für Windows
Eine weitere Neuerung ist ein Container-Storage-Interface für Windows – kurz CSI –, das es sogenannten nicht-privilegierten Containern ermöglicht, privilegierte Speicheroperationen auszuführen.
Im zweiten Durchlauf: Serverside Apply
Unter den interessantesten Neuerungen, die in V 1.18 als Beta-Release veröffentlicht wurden, ist ein serverseitiges Anwendungstool namens Serverside Apply, über das ihr genau nachverfolgen könnt, welche Änderungen an Feldern aller neuer Kubernetes-Objekte wann passiert sind. Das Feature war bereits in V 1.16 in der Beta verfügbar und durchläuft jetzt in V 1.18 eine weitere Testphase.
Topologie Manager
Ein weiteres spannendes Feature, das in V 1.18 in die Beta übergeht, ist eine Topologiemanager-Funktion, die es ermöglichen soll, Workloads auch in einer für niedrige Latenzen optimierten Umgebung auszuführen. Ohne das Feature trafen CPU und Device-Manager die Allokation von Ressourcen betreffende Entscheidungen unabhängig voneinander. Das kann zu unerwünschten Zuweisungen auf Systemen mit mehreren Sockets führen. Unerwünscht bedeutet hier, dass etwa CPUs und Geräte von verschiedenen NUMA-Knoten – NUMA steht für non-uniform memory access – zugewiesen werden, wodurch zusätzliche Latenzzeiten entstehen. Der Topologiemanager sorgt über sogenannte Hints dafür, dass Pod-CPU und Gerät-Ressourcen auf einen gemeinsamen NUMA-Knoten ausgerichtet sind. Der Topologiemanager ist eine Kubelet-Komponente, auf deren Basis andere Kubelet-Komponenten Topologie-konforme Ressourcenzuweisungen vornehmen können. Er verfügt über ein Interface namens Hint Providers, über das Komponenten diese Informationen senden und empfangen können. Auf Node-Ebene verfügt er über eine Reihe von Policies, über die diese Entscheidungen koordiniert werden. Details dazu könnt ihr im zugehörigen Repository auf GitHub nachlesen.
Neue Ingress-Features
Ingress bezeichnet den Eingang zu einem Cluster, also den Punkt, an dem eingehender Traffic ankommt und entsprechend geroutet wird. V 1.18 kommt mit zwei neuen Ingress-Features: Zu einen bringt die neue Version ein neues pathType
-Field, zum anderen eine neue Ressource namens IngressClass
. Über das pathType
-Field kann spezifiziert werden, wie Pfade gematched werden sollen. Zusätzlich zu ImplementationSpecific
– dem Default – gibt es jetzt die Pfad-Typen Exact
und Prefix
. Die zweite Neuerung soll ein Feature, das in vorherigen Versionen überholt wurde, ersetzen: die IngressClass-Ressource dient der Beschreibung eines Ingresstyps innerhalb eines Kubernetes-Clusters. Mithilfe eines Felds namens ingressClassName
können Ingresse die Klasse spezifizieren, zu der sie gehören.
Alle weiteren Neuerungen und Details könnt ihr im offiziellen Kubernetes-Blog nachlesen.
Passend dazu:
- Kubernetes entkompliziert: Microsoft launcht neues Open-Source-Projekt
- Besser entwickeln mit Devops-Praktiken: Continuous Delivery mit Kubernetes
- Container-Virtualisierung: Docker und Kubernetes erfolgreich einsetzen