Die Scheinwerferlampe ist eine Open-Source-Plattform zur Erkundung, Verwaltung und Fehlerbehebung von Kubernetes-Clusterressourcen. Karpenter ist ein Kubernetes-Autoscaling-Projekt, das neue Knoten effizient bereitstellt und deren Lebenszyklus verwaltet. Ein neues Headlamp-Plugin wurde entwickelt, um Echtzeit-Einblicke in die Operationen von Karpenter direkt in der Headlamp-Benutzeroberfläche zu bieten. Dieses Plugin visualisiert die Verbindungen zwischen Karpenter-Ressourcen und Kern-Kubernetes-Objekten. Es zeigt Live-Metriken wie Ressourcenauslastung, zulässige Unterbrechungen und Bereitstellungsverzögerungen an. Benutzer können ausstehende Pods untersuchen und die Skalierungsentscheidungen von Karpenter verstehen, was bei der Fehlerbehebung hilft. Das Plugin bietet auch einen Konfigurationseditor mit Validierung für sichere Live-Bearbeitungen von Karpenter-Ressourcen. Es bietet Echtzeit-Ansichten von Karpenter-Ressourcen wie NodeClaims, während der Cluster skaliert. Ein Dashboard hebt ausstehende Pods und die Gründe für deren Nichtplanbarkeit hervor. Das Plugin wurde mit AWS- und Azure-Karpenter-Anbietern getestet und bietet anbieterspezifische Informationen. Benutzer werden ermutigt, Probleme für nicht getestete Anbieter oder Feedback einzureichen. Anweisungen zur Verwendung sind in der README-Datei des Plugins verfügbar.

Eine neue Alpha-Funktion in Kubernetes erweitert das Storage-Ökosystem um Changed Block Tracking. Dieser Mechanismus ermöglicht es CSI-Storage-Treibern, geänderte Blöcke innerhalb von PersistentVolume-Snapshots effizient zu identifizieren. Durch die Verfolgung von Änderungen auf Blockebene werden Backup-Operationen deutlich schneller und ressourcenschonender. Anstatt ganze Volumes zu scannen, können Backups nun ausschließlich auf die veränderten Daten fokussiert werden. Diese Verbesserung ist in die Container Storage Interface (CSI) und die Kubernetes-Storage-Unterstützung integriert. Die Funktion ist derzeit auf Block-Volumes beschränkt und unterstützt keine File-Volumes. Traditionelle Backup-Methoden kämpfen mit langen Backup-Fenstern, hoher Ressourcenauslastung und erhöhten Speicherkosten aufgrund redundanter Daten. Die Changed Block Tracking API bietet native Kubernetes-Unterstützung für inkrementelle Backups über die CSI-Schnittstelle. Zu den Schlüsselkomponenten gehören die CSI SnapshotMetadata Service API, eine Kubernetes CustomResourceDefinition und ein External Snapshot Metadata Sidecar. Storage-Anbieter müssen spezifische CSI-RPCs implementieren und über Backend-Fähigkeiten zur Verfolgung von Blockänderungen verfügen. Backup-Lösungen müssen die Authentifizierung handhaben, Streaming-Client-Code implementieren und ihre Workflows optimieren, um diese neuen Metadaten zu nutzen. Um die Funktion zu nutzen, stellen Sie sicher, dass Ihr CSI-Treiber Snapshots und Metadaten-Fähigkeiten unterstützt und dass die SnapshotMetadataService Custom Resource registriert ist. Die API bietet die Funktionen GetMetadataAllocated und GetMetadataDelta zur Identifizierung von Blöcken. Zukünftige Pläne beinhalten die Überführung dieser Implementierung in die Beta-Phase basierend auf Feedback und Akzeptanz.

Kubernetes v1.34 führt Pod-Level-Ressourcen ein, die in den Beta-Status übergehen und standardmäßig aktiviert sind. Diese Funktion ermöglicht die Definition von CPU- und Speicherressourcen auf Pod-Ebene, was Flexibilität bietet und die Ressourcenverwaltung vereinfacht. Dies ermöglicht eine einfachere gemeinsame Nutzung von Ressourcen innerhalb eines Pods und reduziert die Komplexität in container-spezifischen Spezifikationen. Pod-Level-Ressourcen sind mit Definitionen auf Container-Ebene kompatibel, wobei erstere Vorrang haben. Diese Funktion verbessert auch das Scheduling und das QoS-Verhalten und ist mit der bestehenden Kubernetes-Funktionalität kompatibel. Um diese Funktion zu nutzen, definieren Sie Ressourcenanforderungen und -limits innerhalb des `resources`-Felds des Pods im Manifest. Pod-Level-Limits wirken als harte Obergrenzen für die gesamte Ressourcenauslastung und beeinflussen die Servicequalität des Pods. Die In-Place-Größenänderung von Pod-Level-Ressourcen wird in dieser Version noch nicht unterstützt. Derzeit können nur CPU-, Speicher- und Hugepages-Ressourcen auf Pod-Ebene angegeben werden. Die Pod-Level-Ressourcen-Funktion ist nicht mit Windows-Pods kompatibel. Benutzer sollten über Kubernetes-Kanäle Feedback geben.

Kubernetes v1.34 führt eine wesentliche Verbesserung ein: die automatische Wiederherstellung nach fehlgeschlagener Volumenerweiterung. Zuvor erforderte die Korrektur von Erweiterungsfehlern, wie z. B. die Angabe einer falschen Speichergröße, manuelles Eingreifen und Cluster-Admin-Rechte. Diese neue Funktion ermöglicht es Benutzern, die angeforderte PVC-Größe zu reduzieren, wenn bei der Erweiterung ein Fehler gemacht wurde, solange die Erweiterung noch nicht abgeschlossen ist. Kubernetes korrigiert dann automatisch die Größe, gibt alle verbrauchten Quoten zurück und ändert die Größe des PersistentVolume. Ein Beispiel veranschaulicht, wie ein Benutzer einen Tippfehler in der Speicheranforderung korrigieren kann. Die korrigierte Größe muss immer noch größer sein als die ursprüngliche Volume-Größe, da das Verkleinern von Volumes nicht unterstützt wird. Die Implementierung umfasste eine komplette Überarbeitung der Volumenerweiterung und die Einführung neuer API-Felder zur Überwachung des Fortschritts der Erweiterung. Verbesserte Fehlerbehandlung und -berichterstattung sind jetzt vorhanden, wobei Fehler als PVC-Bedingungen bestehen bleiben und fehlgeschlagene Erweiterungen mit einer langsameren Rate wiederholt werden. Diese Funktion behebt auch langjährige Fehler im Größenänderungs-Workflow. Benutzer werden gebeten, alle aufgetretenen Probleme zu melden. Die Entwicklung dieser Funktion profitierte von dem Feedback und den Beiträgen verschiedener Personen und der Kubernetes-Community.

Dynamische Ressourcenallokation (DRA) in Kubernetes verwaltet knappe Ressourcen wie Geräte für Pods und geht über die einfache Gerätezuweisung hinaus. DRA ermöglicht Anfragen nach bestimmten Geräten mit benutzerdefinierten Konfigurationen, einschließlich der gemeinsamen Nutzung von Ressourcen. Dieser Blog beschreibt die neue Funktion der verbrauchbaren Kapazität von DRA in Kubernetes 1.34, die für eine feinere Gerätefreigabe entscheidend ist. Die verbrauchbare Kapazität ermöglicht die gemeinsame Nutzung eines Geräts über mehrere ResourceClaims oder DeviceRequests hinweg, auch über Namespaces hinweg. Der Scheduler unterstützt jetzt die Zuweisung von Teilen der Geräteressourcen und verwaltet die Gesamtkapazität. Eine neue DistinctAttribute-Einschränkung verhindert, dass ein einzelnes Gerät innerhalb desselben Claims mehrfach zugewiesen wird. Diese Funktion erfordert die Aktivierung des DRAConsumableCapacity-Feature-Gates in verschiedenen Kubernetes-Komponenten. Entwickler können mehrere Zuweisungen zulassen, indem sie AllowMultipleAllocations festlegen, und können Richtlinien für Gerätekapazitätsanforderungen definieren. Benutzer können Geräteteile über ResourceClaims anfordern, und der Gerätestatus kann dynamische Informationen wie IP-Adressen enthalten. Diese Erweiterung unterstützt bandbreitenbewusstes Networking und die gemeinsame Nutzung von Geräten durch mehrere Mandanten und verbessert die Planung und Ressourcenkontrolle. Der Blog ermutigt zu Experimenten und Feedback, um DRA weiter zu verfeinern.

Kubernetes v1.34 führt ein Alpha-Feature ein, das Einblicke in den Zustand spezialisierter Hardware wie GPUs in Pods ermöglicht. Diese neue Funktionalität, die auf KEP-4680 basiert, erweitert die Dynamic Resource Allocation (DRA)-Treiber. Der Gerätezustand wird nun über DRA direkt in das Statusfeld eines Pods gemeldet. Die Anzeige des Gerätezustands hilft Benutzern, Probleme in zustandsbehafteten Anwendungen oder langlaufenden Jobs schnell zu diagnostizieren. Dies ermöglicht es Betreibern und Entwicklern, zugrunde liegende Hardwarefehler zu identifizieren. Dies geschieht über einen neuen gRPC-Gesundheitsdienst, der in der API-Gruppe dra-health definiert ist. Der Kubelet integriert sich in DRA-Treiber und speichert Gesundheitsaktualisierungen in einem Cache. Der Pod-Status wird aktualisiert, wenn sich der Zustand eines Geräts ändert, was sich im Feld `allocatedResourcesStatus` widerspiegelt. Dies ermöglicht es Benutzern, fehlerhafte Hardware zu identifizieren, indem sie den Status eines Pods mit `kubectl` inspizieren. Um das Feature zu nutzen, muss das Feature-Gate `ResourceHealthStatus` aktiviert sein. Geplante Verbesserungen umfassen detaillierte Gesundheitsmeldungen und konfigurierbare Timeouts. Die Kubernetes-Community zielt darauf ab, die Behandlung von Hardwarefehlern zu verbessern und freut sich über Benutzerfeedback.

Kubernetes hat Volume Group Snapshots als Alpha-Funktion eingeführt, die sich zu Beta und nun zu einer zweiten Beta-Version entwickelt hat. Diese Funktion bietet absturzkonsistente Snapshots für eine Gruppe von Volumes über Erweiterungs-APIs. Kubernetes verwendet Label-Selektoren, um PersistentVolumeClaims für das Snapshotting zu gruppieren, mit dem Ziel, Workloads aus einem Snapshot wiederherzustellen. Die Funktion stützt sich für die Implementierung auf CSI-Volume-Treiber. Die kürzlich veröffentlichte Beta 2-Version behebt ein Problem mit dem restoreSize-Feld, wenn der CSI-Treiber den ListSnapshots RPC-Aufruf nicht unterstützt. Die v1beta2-API führt die VolumeSnapshotInfo-Struktur und die VolumeSnapshotInfoList für detaillierte Snapshot-Informationen ein. Bestehende v1beta1-Objekte werden mithilfe eines Conversion-Webhooks in v1beta2 konvertiert. Das Projekt strebt die allgemeine Verfügbarkeit (GA) auf der Grundlage von Community-Feedback und Akzeptanz an. Es werden Ressourcen für weiteres Lernen bereitgestellt, darunter die Design-Spezifikation, das Code-Repository und die CSI-Dokumentation. Die Community heißt neue Mitwirkende im Kubernetes Storage SIG und der Data Protection Working Group willkommen.

Die Verbesserung trennt die Knotenlebenszyklusverwaltung und die Pod-Eviktion in separate Komponenten. Zuvor war der Knotenlebenszyklus-Controller sowohl für die Kennzeichnung von Knoten als fehlerhaft als auch für die Eviktion von Pods zuständig. Jetzt verwaltet ein dedizierter Taint-Eviktions-Controller die Pod-Eviktionen. Der Knotenlebenszyklus-Controller ist ausschließlich für das Anwenden von Taints auf fehlerhafte Knoten verantwortlich. Diese Trennung verbessert die Codeorganisation und erleichtert die Anpassung der Taint-basierten Eviktion. Das Feature-Gate SeparateTaintEvictionController ist nun allgemein verfügbar. Benutzer können die Taint-basierte Eviktion deaktivieren, indem sie den kube-controller-manager konfigurieren. Weitere Details finden Sie im KEP und in der Beta-Ankündigung. Die Entwickler würdigen die bedeutenden Beiträge zahlreicher Personen, die diese Funktion zur Stabilität gebracht haben.

Die Konfiguration des cgroup-Treibers war für Kubernetes-Benutzer historisch gesehen ein komplexes Problem. Linux-Systeme verwenden zwei cgroup-Treiber: cgroupfs und systemd. Zuvor mussten sowohl der Kubelet als auch die CRI-Implementierung, wie z. B. containerd oder CRI-O, identisch konfiguriert werden, um Kubelet-Fehlfunktionen ohne klare Fehlermeldungen zu vermeiden. Dies führte oft zu erheblicher Frustration bei Cluster-Administratoren. In Kubernetes v1.28.0 wurde das Feature-Gate KubeletCgroupDriverFromCRI eingeführt. Dies ermöglicht es dem Kubelet, die CRI-Implementierung nach ihrem bevorzugten cgroup-Treiber abzufragen. Nach mehreren Release-Zyklen hat dieses Feature nun in Kubernetes 1.34.0 den General Availability (GA)-Status erreicht. Um dies zu nutzen, müssen Administratoren sicherstellen, dass ihre CRI-Implementierung ausreichend aktualisiert ist. Containerd benötigt Version v2.0.0 oder höher, während CRI-O Version v1.28.0 oder höher benötigt. Kubernetes stellt die Unterstützung für containerd v1.y-Versionen ein. Während sich CRI-O-Releases an den Kubernetes-Versionen orientieren, hat containerd seinen eigenen Release-Zyklus, wobei die Feature-Unterstützung nur in v2.0 und höher vorhanden ist. Kubernetes 1.34 unterstützt weiterhin ältere containerd LTS-Releases wie v1.7. Die Kubernetes SIG Node Community hat einen Zeitplan für die schrittweise Einstellung der Unterstützung für containerd v1.y festgelegt. Die letzte Kubernetes-Version, die diese Unterstützung enthalten wird, ist die finale Version von v1.35, wobei die Unterstützung in v1.36.0 endet. Um diesen Übergang zu erleichtern, kann eine Metrik namens kubelet_cri_losing_support überwacht werden. Wenn diese Metrik eine containerd-Version von 1.36.0 anzeigt, signalisiert dies, dass die containerd-Laufzeitumgebung für zukünftige Anforderungen veraltet ist. Administratoren müssen containerd auf v2.0 oder eine neuere Version aktualisieren, bevor oder gleichzeitig mit dem Upgrade des Kubelet auf v1.36.0.

Die Fähigkeit von CSI-Treibern, die Anzahl der an Knoten anhängbaren Volumes zu aktualisieren, wurde in Kubernetes v1.34 von Alpha auf Beta hochgestuft. Dieses Feature zielt darauf ab, die Genauigkeit der Planung von zustandsbehafteten Pods zu verbessern. Zuvor meldeten CSI-Treiber statische Volume-Limits, die veraltet sein konnten. Gründe für veraltete Informationen sind externe Volume-Operationen, der Hardwareverbrauch von Slots und Interaktionen zwischen mehreren Treibern. Diese Ungenauigkeit konnte dazu führen, dass Pods nicht gestartet werden konnten und im Zustand ContainerCreating stecken blieben. Die neue Funktionalität ermöglicht es CSI-Treibern, die Kapazitäten für die Knotenanhängung zur Laufzeit dynamisch zu melden. Kubernetes unterstützt nun zwei Update-Mechanismen: periodische Aktualisierungen und sofortige Aktualisierungen bei Fehlern beim Anhängen. Um dieses Beta-Feature zu aktivieren, muss das MutableCSINodeAllocatableCount-Feature-Gate auf kube-apiserver und kubelet aktiviert werden. CSI-Treiber können mit nodeAllocatableUpdatePeriodSeconds für periodische Aktualisierungen konfiguriert werden, wobei ein Mindestintervall erzwungen wird. Sofortige Aktualisierungen werden durch ResourceExhausted-Fehler während des Anhängens von Volumes ausgelöst, wodurch Pods vor permanenten Fehlern geschützt werden. Benutzer werden ermutigt, dieses Feature in v1.34 zu aktivieren und zu testen und Feedback für seine Weiterentwicklung zur allgemeinen Verfügbarkeit zu geben.