Orchestrierung: Kubernetes 1.16 vereinfacht API-Erweiterung

Die Container-Orchestrierung Kubernetes stabilisiert in Version 1.16 die Custom Resources, die als Basis für API-Erweiterungen dienen. Ein Topology-Manager-Kubelet verteilt Hardware-Ressourcen feingranularer und der Cluster-Overhead wird reduziert.

Artikel veröffentlicht am 19. September 2019, 14:45 Uhr, Kristian Kißling/Linux Magazin/Sebastian Grüner

Kubernetes ist in Version 1.16 erschienen. (Bild: Kubernetes)

Das Kubernetes-Projekt hat Version 1.16 seiner Plattform zur Container-Orchestrierung veröffentlicht. Damit sind die sogenannten Custom Resources erstmals stabil verfügbar. Es handelt sich dabei um Erweiterungen des Kubernetes API. Im Rahmen einer Beta-Phase konnte diese seit Version 1.7 der Software getestet werden.

In Kubernetes ist eine Resource ein Endpoint, zu dem eine Reihe von API-Objekten gehören. Über sogenannte Custom Resource Definitions (CRD) lassen sich Komponenten in die Containerplattform einbinden, die nicht unbedingt zum Lieferumfang gehören. Admins binden diese Komponenten zur Cluster-Laufzeit dynamisch ein. Inzwischen sind jedoch viele Core-Funktionalitäten in Custom Resources auslagert, um Kubernetes möglichst modular zu halten.

Mit Kubernetes 1.16 gelten Custom Resources nun als ausgereift und sind im HTTP-API-Space über apiextensions.k8s.io/v1 zu finden, das vorherige /v1beta1 fällt also weg. Zugleich müssen Kubernetes-Admins auf ein paar Besonderheiten achten, da einige Dinge, die zuvor optional waren, nun obligatorisch werden.

Dazu zählen etwa Structural Schemas, die dafür sorgen, dass die API-Server genau wissen, welche Felder sich legitim in einer CRD befinden. Auch Validation Schemata und Pruning, das unbekannte Felder entfernt, gehören zu den verpflichtenden Neuerungen, die garantieren sollen, eine stabile API zu erhalten.

Endpoint Slices sollen Skalierbarkeit verbessern

Als Alternative zu den Endpoints, aber noch im Alpha-Stadium verhaftet, sind die neu eingeführten Endpoint Slices. Sie sollen Kubernetes skalierbarer machen und betreffen besonders den Netzwerk-Bereich. Endpoint Resources repräsentieren in großen Clustern die Network Endpoints sämtlicher Pods, mitunter Tausende. Das skaliert schlecht, und Dienste um Endpoints zu ergänzen oder Endpoints zu entfernen, erzeugt einen großen Mehraufwand im Cluster.

Endpoint Slices splitten die Menge an zu verwaltenden Endpoints aber auf und begrenzen sie auf 100. Weil dann nur noch Slices der aktualisierten Teile durch den Cluster wandern, senkt das den Verwaltungsaufwand. Zudem bieten sich Endpoint Slices als erweiterbare Ressourcen an und spielen sowohl beim neuen Topology-Attribut eine Rolle als auch beim Verwalten von Adresstypen (IPv4/IPv6).

Ebenfalls hinzugekommen ist eine neue Kubelet-Komponente im Alpha-Status: der Topology Manager. Dieser verteilt Hardware-Ressourcen intelligenter auf einem Knoten, weil dieser weiß, wo sich Arbeitsspeicher, CPUs und Geräte befinden und welche Kombination die beste Performance liefert.

Eine Funktion namens Dual-Stack-Networking (Alpha) erlaubt es, Pods und Services sowohl über IPv4- als auch über IPv6-Adressen zu adressieren. Metriken lassen sich in einer Metrics Registry sammeln, gefeilt haben die Entwickler zudem am Umgang mit Datenträgern (Volumes). So ist Volume Resizing nun im Beta-Stadium angekommen. Weitere Details liefern die Release Notes.