Container: Kubernetes 1.19 bietet mehr Vorhersehbarkeit und Stabilität

Inhaltsverzeichnis

Die Kubernetes-Community hat die Version 1.19 ihrer Container-Orchestrierungsplattform freigegeben. Sie folgt auf das im März veröffentlichte Kubernetes 1.18 und ist offenbar das Release in der Geschichte der Software, das am längsten bis zur Fertigstellung gebraucht hat, unter anderem natürlich auch wegen der Beeinträchtigungen durch die COVID-19-Pandemie. Von statistischer Seite lässt sich konstatieren, dass zwölf Erweiterungen nun als stabil gelten dürfen, 18 weitere haben nun Beta-Status und wiederum 13 weitere haben den Schritt Richtung Alpha vollzogen.

Die lange Reise des Ingress Controller

Den Kubernetes Ingress Controller gibt es als API bereits seit Kubernetes 1.1, er ist seitdem (November 2015) aber immer im Beta-Stadium verblieben. Er dient dazu, den externen Zugriff auf Dienste in einem Cluster zu kontrollieren, um HTTP- und HTTPS-Routen offenzulegen. Mit ihm lassen sich Lastausgleich und SSL/TLS verwalten sowie namensbasierte virtuelle Hosting-Funktionen bereitstellen. Nun hat man ihn als reif genug deklariert, um ihn zu den Networking v1 APIs hinzuzufügen.

Als stabil gilt in Kubernetes 1.19 nun die Fähigkeit, die Übergänge von einer Beta- zu einer stabilen Version automatisch verfolgen und darauf reagieren zu können. Das damit verbundene Ziel ist es zu verhindern, dass APIs über einen längeren Zeitraum in der Beta-Phase verbleiben. In der Folge sind Tags erforderlich, die anzeigen, wann eine API mit Beta-Status eingeführt wurde. Eine API, die im Beta-Stadium bleibt, wird drei Versionen später veraltet und drei weitere danach entfernt. In dem Kontext gibt es jetzt auch Warnmeldungen für API-Consumer und Metriken für Cluster-Administratoren. Dieses Feature hat aber noch Beta-Status. Selbiges gilt für das Hinzufügen des AppProtocol bei Services und Endpoints.

Viel Security

Die Sicherheitseinrichtung im Linux-Kernel seccomp (Security Computing Mode) hat jetzt in Kubernetes 1.19 auch GA-Status (General Availability). Mit ihr lässt sich unter anderem die Anzahl der Systemaufrufe einschränken, die Anwendungen durchführen können. seccomp ist seit Kubernetes 1.3 Bestandteil der Orchestrierungsplattform, allerdings mit einigen Einschränkungen: so war beim Einsatz von seccomp-Profilen auf Pods eine Anmerkung zu einer PodSecurityPolicy erforderlich.

Seit Kubernetes 1.8 enthalten Cluster einen (Beta-)Prozess, um das anfängliche Zertifikat/Schlüsselpaar zu erhalten und bei Ablauf des Zertifikats zu rotieren. In Kubernetes 1.19 gilt das Feature nun als stabil. Außerdem hat der NodeRestriction-Admission-Controller jetzt ausreichenden Reifegrad, sodass er für den Produktiveinsatz empfohlen wird.

Scheduler-Profile und Pod Topology Spread

Die Möglichkeit, das Verhalten des Kubernetes-Schedulers anzupassen, indem eine Konfigurationsdatei geschrieben und ihr Pfad als Kommandozeilenargument übergeben wird, ist zur Beta-Phase gelangt. Zusammen mit der Beta-Version der Scheduler-Profile, die es dem Scheduler erlauben, mehrere Scheduler-Profile auszuführen, die mit einem Scheduler-Namen verknüpft sind, bedeutet das, dass Kubernetes eine größere und breitere Palette von Workloads und Anwendungsfällen unterstützen kann.

Die "Pod Topology Spread"-Funktion, die Topologien automatisch gewichtet und eine bessere Differenzierung zwischen Knoten und Zonen anwendet, um ausgewogenere Ergebnisse über Einschränkungen hinweg zu erzielen, ist jetzt mit Version 1.19 stabil. Zuvor musste man die Inter-Pod-Anti-Affinität verwenden, die es nicht zulässt, dass mehr als ein Pod in einer Fehlerdomäne existiert. Die neue Funktion unterstützt mehr als einen Pod in einer Fehlerdomäne. Ein weiteres sicherlich bemerkenswertes Features ist eine neue Option für podSpecs, die die Präemptionierung vorhandener Arbeitslasten verhindert, was insbesondere bei der Verwendung bestimmter Arten von lang laufenden Batch-Workloads der Fall sein kann.

Kubernetes 1.19 führt neue Methoden in die klog-Bibliothek ein, die eine strukturiertere Schnittstelle für die Formatierung von Protokollnachrichten bieten sollen. Jeder vorhandenen formatierten Protokollmethode (Infof, Errorf) steht nun eine strukturierte Methode (InfoS, ErrorS) gegenüber. Die neuen Protokolliermethoden akzeptieren Protokollnachrichten als erstes Argument und eine Liste von Schlüssel-Werte-Paaren als variadisches zweites Argument. Dieser Ansatz ermöglicht wohl die inkrementelle Übernahme der strukturierten Protokollierung, ohne eine gesamte Kubernetes-Installation auf einmal in eine neue API zu konvertieren.

Mehr Informationen

Bislang wurden Kubernetes-Release für neun Monate offiziell unterstützt. Eine Umfrage hatte jedoch ergeben, dass viele Kubernetes lieber länger auf eine Kubernetes-Ausgabe setzen würden. Deswegen wurde das LTS-Zeitfenster (Long-Term Support) jetzt auf ein Jahr verlängert.

Wer tiefer in die Neuerungen von Kubernetes 1.19 einsteigen will, findet in der Ankündigung einen guten Start. Kubernetes-Mitentwickler wie Red Hat und VMware bieten in aktuellen Blogbeiträgen weitere Hintergrundinformationen. Geplant ist, dass mit Kubernetes 1.20 ein weiteres Release erscheinen soll – wohl im Dezember.

(ane)