Kubernetes v1.33 wurde am vergangenen Dienstag veröffentlicht, und wie immer haben wir bei NWS genau geschaut, was neu ist, von welchen Funktionen sich das Projekt getrennt hat, und welche Features besonders herausstechen. Die Highlights inklusive praktischen Beispielen findest du wie immer in unserem Kubernetes Release Review!
Kubernetes v1.33 trägt den Releasenamen Octarine, benannt nach der magischen achten Farbe in Terry Pratchetts Fantasy-Universum. Dieser Name ist passend – neue Features wie Sidecar Container oder in-place Skalierung von Podressourcen fühlen sich tatsächlich magisch an. Den Anfang unseres Kubernetes Release Review machen allerdings die angekündigten Deprecations.
Deprecations in Kubernetes v1.33 Octarine
Wie bei jedem Kubernetes Release gibt es einige Features, die deprecated wurden. Das geschieht normalerweise aufgrund der Projektentwicklung in eine neue Richtung oder nach Entstehung eines neuen, besseren Standards. Ein gutes Beispiel ist die Endpoints API.
Deprecation der Endpoint API zugunsten der EndpointSlices API
Die EndpointSlices API ist bereits seit Kubernetes v1.21 als stable kategorisiert und damit bereits seit einiger Zeit der de-facto Nachfolger der alten, simpleren Endpoints API innerhalb von Kubernetes. War die Endpoints API zwar einfach zu verstehen und simpel umgesetzt, hatte sie doch hier und da Probleme in größeren Setups.
Diese Probleme wurden durch die Einführung der EndpointSlices API behoben und neue Funktionen integriert, z.B. Dual-Stack Networking. Diese Deprecation betrifft dich vermutlich nur, wenn du die alte Endpoints API im Rahmen von Scripts oder Automatisierungen direkt nutzt. Ein ausführlicher Blogpost zur Migration wurde bereits angekündigt.
Das ursprüngliche Kubernetes Enhancement Proposal (KEP) zur Deprecation findest du hier.
Deprecation des in-tree gitRepo Volumetreibers
Der gitRepo Volumetyp ist bereits seit Kubernetes v1.11 deprecated, was fast 7 Jahren entspricht. Seitdem gab es immer wieder Sicherheitsbedenken hinsichtlich des gitRepo Volumetyps und der Möglichkeit, durch ihn Remote Code Execution auf Clusternodes zu erlangen.
In Kubernetes v1.33 wurde der Quellcode nun aus dem Kubernetes-Projekt entfernt. Als sinnvolle Alternative führen die Release Notes git-sync oder Init Container an, zudem sind gitVolumes weiterhin in der Kubernetes API vorhanden und Pods mit gitRepo Volumes können erstellt werden. Für die Ausführung solcher Pods muss auf den Kubelets eines Clusters das Featuregate GitRepoVolumeDriver=true gesetzt sein, andernfalls wird eine transparente Fehlermeldung an den Nutzer zurückgegeben.
Durch dieses erneute Opt-In können gitRepo Volumes noch für die nächsten drei Versionen genutzt und eine Migrationsstrategie erarbeitet werden.
Das ursprüngliche KEP zur Deprecation findest Du hier.
Eine komplette Übersicht aller fünf Deprecations in Kubernetes v1.33 Octarine findest du in den Release Notes.
Highlights in Kubernetes v1.33 Octarine
Nachdem wir die wegfallenden Features nun abgehakt haben, können wir uns dem spannenderen Teil unseres Kubernetes Release Reviews widmen: Den neuen Funktionen in Kubernetes v1.33 Octarine!
Hier finden wir zwei Features besonders interessant: Sidecar-Container sind nun stable, und vertikale Skalierung von Pods in-place ist beta. Beide Änderungen erklären wir dir in den nächsten Absätzen.
Sidecar Container in Kubernetes v1.33
Sogenannte Sidecar Container sind seit seinen frühen Tagen fester Bestandteil von Kubernetes. Hierbei wird ein zusätzlicher Container als weiterer regulärer Container oder vor Containerstart laufender Init-Container innerhalb eines Pods definiert. Häufige Anwendungsfälle sind bspw. Service Meshes, Log- und Metrikscraper, Secretmanagement und andere Hilfsservices.
Problematik bisheriger Sidecars als Init Container
Durch die bestehenden Möglichkeiten der Umsetzung ergaben sich allerdings immer wieder Probleme, je nach Anwendungsfall:
- Ist das Sidecar als Init-Container definiert, wartet der Kubelet mit der Erstellung des Hauptcontainers, bis der Init-Container terminiert ist. Dieses Modell ist für permanent laufende Agenten für Netzwerk, Logging und Scraping also unbrauchbar.
- Ist das Sidecar als regulärer Container definiert, ist die Start-Reihenfolge der regulären Container nicht deterministisch. Es könnte also sein, dass die eigentliche Anwendung vor dem Sidecar startet, und somit Informationen nicht geloggt, Metriken nicht gescraped, oder eine Netzwerkverbindung nicht aufgebaut werden kann. Genauso verhält es sich bei der Terminierung eines Pods.
- Durch die oft niedrigeren Ressourcenanforderungen von Sidecars im Vergleich zu den Anwendungscontainern eines Pods sind Sidecars das bevorzugte Ziel des Kubelets, wenn aufgrund von Ressourcenmangel Container terminiert werden müssen. Im Falle einer gesetzten
restartPolicy: Never, z.B. bei Jobs, wird das Sidecar in einem solchen Fall nicht neugestartet.
Mit der Einführung von Sidecar Containern als explizites Deploymentmodell ermöglicht Kubernetes eine definierte, verlässliche Handhabe solcher Prozesse:
- Sidecar Container sind Init Container, die auch nach Podstart weiterlaufen und den Start des Anwendungscontainers nicht blockieren.
- Sidecar Container werden zum Zeitpunkt der Terminierung eines Pods nach den Anwendungscontainern beendet.
- Reguläre Init Container und Sidecar Container können gemischt deklariert werden; die Startreihenfolge wird dabei weiterhin wie gewohnt beachtet.
Hierdurch ist es in Kubernetes seit v1.29 wesentlich einfacher, zusätzlich benötigte Prozesse für Monitoring, Logging, Housekeeping und sonstige Anwendungszwecke zu definieren und zu verwalten.
Definition von Sidecar Containern
Möglich macht das ein neues Feld restartPolicy in der Spezifikation von initContainers eines Pods:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
labels:
app: myapp
spec:
replicas: 1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: alpine:latest
command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done']
volumeMounts:
- name: data
mountPath: /opt
initContainers:
- name: logshipper
image: alpine:latest
restartPolicy: Always
command: ['sh', '-c', 'tail -F /opt/logs.txt']
volumeMounts:
- name: data
mountPath: /opt
volumes:
- name: data
emptyDir: {}Die gesetzte restartPolicy Always im Init Container logshipper sorgt dafür, dass das Sidecar unabhängig vom Anwendungscontainer myapp und etwaigen anderen Init Containern (neu-)gestartet oder gestoppt werden kann. Das Sidecar startet garantiert vor dem Anwendungscontainer und wird nach diesem terminiert.
Im Gegensatz zu regulären Init Containern unterstützen Sidecards wie reguläre Container Probes (livenessProbe, readinessProbe, startupProbe) zur Kontrolle ihres Lebenszyklus. Bei definierten Probes werden Sidecars somit auch in die Evaluierung des Ready/Healthy Status eines Pods mit einbezogen.
Diese neuen Möglichkeiten des Sidecar Managements durch das als stable kategoriesierte Feature in Kubernetes v1.33 Octarine sind definitiv unser persönliches Highlight dieses Kubernetes Release Reviews. Das zugrundeliegende KEP findest du hier. Weitere Informationen zu Sidecar Containern finden sich in der Kubernetes Dokumentation.
In-Place Skalierung von Podressourcen in Kubernetes v1.33
Das zweite bereits erwähnte Feature, das wir in unserem Kubernetes Release Review besonders hervorheben wollen, bezieht sich auf die vertikale Skalierung von Podressourcen – ohne einen bisher notwendigen Neustart!
Kubernetes ermöglicht bereits seit langem das Management von Ressourcen für Pods und Container. Im Gegensatz zur horizontalen Skalierung von Workloads (durch das Hinzufügen/Wegnehmen von Workloadreplikas) war vertikale Skalierung bisher allerdings immer mit einem Neustart aller betroffenen Pods und Container verbunden.
Vorteile von In-Place Pod Resizing
Das momentan als beta kategorisierte Feature In-place resource resize for vertical scaling of Pods ermöglicht nun genau diesen Vorgang ohne die Notwendigkeit eines Neustarts. Hierdurch ergeben sich einige interessante Anwendungsmöglichkeiten:
- Stateful Workloads können ohne Downtime hochskaliert werden.
- Zugewiesene Ressourcen können bei geringer Last verringert werden.
- Anwendungen, die zur Initialisierung deutlich mehr Ressourcen benötigen als im regulären Betrieb, können entsprechend gemanagt werden.
Die Kubernetes Dokumentation gibt einen guten Überblick über das Resizing von Podressourcen, inkl. Beispielen.
Definition von In-Place Pod Resizing
Da das Feature in Kubernetes v1.33 Octarine standardmäßig aktiv ist, muss grundsätzlich nichts beachtet werden. Für eine explizite Definition des gewünschten Verhaltens eines Pods im Falle eines Resizings steht das Feld resizePolicy zur Verfügung. Mit diesem kann das Restart-Verhalten eines Pods nach erfolgtem Resizing pro betroffener Ressource festgelegt werden:
apiVersion: v1
kind: Pod
metadata:
name: resize-demo
spec:
containers:
- name: pause
image: registry.k8s.io/pause:3.8
resizePolicy:
- resourceName: cpu
restartPolicy: NotRequired # Default, but explicit here
- resourceName: memory
restartPolicy: RestartContainer
resources:
limits:
memory: "200Mi"
cpu: "700m"
requests:
memory: "200Mi"
cpu: "700m"In diesem Beispiel ist festgelegt, dass bei einem CPU Resizing kein Neustart des Pods benötigt wird; Bei Resizing des zugewiesenen Arbeitsspeicher hingegen wird ein Restart des Containers benötigt, um eine Propagierung der neu gesetzten Ressourcen zu garantieren.
Die im Beispiel aufgeführten Restart Policies (NotRequired bzw. RestartContainer) sind die einzig momentan verfügbaren. Auch ist das Feature momentan nur für CPU und Memory Ressourcen verfügbar. Eine Liste aller momentanen Limitierungen findest du in der Kubernetes Dokumentation.
Der Vertical Pod Autoscaler (VPA) kann bisher noch nicht mit dem neuen Feature umgehen. Eine offene PR dazu auf GitHub lässt sich hier verfolgen.
Kubernetes v1.33 Octarine – Feels like magic!
Unser Fazit dieses Kubernetes Release Reviews: Kubernetes v1.33 Octarine wird seinem Namen mehr als gerecht. Die neu eingeführten oder fortgeführten Änderungen des Projekts haben das Potenzial, uns in bestehenden Umgebungen viel Arbeit z.B. für Sidecar-Management oder aufwendige Skalierungsframeworks abzunehmen, und fühlen sich für Newcomer und alte Hasen gleichermaßen „wie Zauberei“ an.
Eine vollständige Übersicht aller in Kubernetes v1.33 enthaltenen Änderungen findest du entweder in den offiziellen Release Notes oder im begleitenden Blogpost des Kubernetes Projekts.
Und wie immer gilt: Solltest du einige dieser Features umsetzen wollen oder sonstige Hilfe im Betrieb von Kubernetes in der NETWAYS Cloud oder sonstwo brauchen, wende dich gerne jederzeit an einen unserer MyEngineers® – wir freuen uns! Andernfalls lesen wir uns im nächsten Kubernetes Release Review für v1.34 im August.
0 Kommentare