RSS-Kubernetes-Blog - TheNote.app

RSS-Kubernetes-Blog
Folgen

Die offizielle Homepage von Kubernetes, einem Container-Orchestrierungssystem für die Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. Diese Plattform bietet umfassende Dokumentation zu Kubernetes, ein von der Cloud Native Computing Foundation gepflegtes Projekt. Es enthält Details zum Ausführen von stateless und stateful Anwendungen, Batch-Jobs und CI/CD-Arbeitsabläufen mit Kubernetes. Die Webseite enthält detaillierte Anleitungen, Tutorials, Referenzmaterial, API-Dokumentation und Initiativen für die Community-Engagement, um Benutzer bei der Arbeit mit Kubernetes zu unterstützen und die Funktionsweise effektiv zu nutzen, um cloudbasierte Anwendungen effizient zu verwalten.

RSS kubernetes.io

Kubernetes Blog kubernetes.io

RSS Hunter • 22. Aug. 2024

Notizfaden

Vorstellung des Headlamp-Plugins für Karpenter – Skalierung und Sichtbarkeit

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.

Introducing Headlamp Plugin for Karpenter - Scaling and Visibility kubernetes.io

RSS Hunter • 6. Okt. 2025

Ankündigung der Unterstützung für die Changed Block Tracking API (Alpha)

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.

Announcing Changed Block Tracking API support (alpha) kubernetes.io

RSS Hunter • 25. Sept. 2025

Kubernetes v1.34: Pod-Level-Ressourcen sind in die Beta-Phase übergegangen

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: Pod Level Resources Graduated to Beta kubernetes.io

RSS Hunter • 22. Sept. 2025

Kubernetes v1.34: Wiederherstellung nach fehlgeschlagener Volume-Erweiterung (GA)

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.

Kubernetes v1.34: Recovery From Volume Expansion Failure (GA) kubernetes.io

RSS Hunter • 19. Sept. 2025

Kubernetes v1.34: DRA Verbrauchsleistung

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: DRA Consumable Capacity kubernetes.io

RSS Hunter • 18. Sept. 2025

Kubernetes v1.34: Pods melden DRA-Ressourcengesundheit

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 v1.34: Pods Report DRA Resource Health kubernetes.io

RSS Hunter • 17. Sept. 2025

Kubernetes v1.34: Verschieben von Volume Group Snapshots zu v1beta2

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.

Kubernetes v1.34: Moving Volume Group Snapshots to v1beta2 kubernetes.io

RSS Hunter • 16. Sept. 2025

Kubernetes v1.34: Entkoppeltes Taint-Management ist jetzt stabil

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.

Kubernetes v1.34: Decoupled Taint Manager Is Now Stable kubernetes.io

RSS Hunter • 15. Sept. 2025

Kubernetes v1.34: Autokonfiguration für Node Cgroup Driver wird GA

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.

Kubernetes v1.34: Autoconfiguration for Node Cgroup Driver Goes GA kubernetes.io

RSS Hunter • 12. Sept. 2025

Kubernetes v1.34: Mutable CSI Node Allocatable erreicht Beta

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.

Kubernetes v1.34: Mutable CSI Node Allocatable Graduates to Beta kubernetes.io

RSS Hunter • 11. Sept. 2025

Kubernetes v1.34: Verwende einen Init-Container, um App-Umgebungsvariablen zu definieren

Kubernetes verwendet traditionell ConfigMaps und Secrets für Umgebungsvariablen, was Komplexität und zusätzliche API-Aufrufe verursacht. Die separate Verwaltung von Pods und ihren Konfigurationen, insbesondere bei Updates, kann eine Herausforderung darstellen. Dies gilt insbesondere für Vendor-Container, die Umgebungsvariablen benötigen, ohne diese hart zu codieren oder Volume-Mounts zu verwenden.Ein neues Alpha-Feature namens EnvFiles bietet eine alternative Lösung für diese Szenarien. Wenn das EnvFiles-Feature-Gate aktiviert ist, kann das Kubelet Umgebungsvariablen für einen Container direkt aus einer Datei innerhalb eines emptyDir-Volumes laden. Dies eliminiert die Notwendigkeit, die Datei in den Container selbst zu mounten. Die Kernfunktionalität ermöglicht es Kubernetes, eine Datei zu parsen, die oft von einem Init-Container generiert wird, und beim Start Umgebungsvariablen für den Hauptcontainer festzulegen.Die Datei befindet sich in einem emptyDir-Volume, einem temporären Speicher, der für die Lebensdauer des Pods gilt. Der Hauptcontainer muss dieses Volume nicht mounten; das Kubelet übernimmt das Lesen der Datei und das Injizieren der Variablen. Die Definition dieser Variablen beinhaltet die Verwendung des fileKeyRef-Felds in der Pod-Spec, das den Dateipfad und den zu extrahierenden Schlüssel angibt.Das Dateiformat unterstützt eine KEY=VALUE-Syntax, und für diese Alpha-Phase muss es in ein emptyDir-Volume geschrieben werden. Ein Init-Container ist erforderlich, um die Datei in das emptyDir-Volume zu schreiben, aber der Hauptanwendungscontainer benötigt keinen Zugriff auf das Volume. Obwohl dieses Feature sensible Daten verarbeiten kann, ist es wichtig zu beachten, dass Knotenbetreiber mit Dateisystemzugriff diese Daten potenziell aus emptyDir-Volumes abrufen könnten. Daher sind robuste Cluster-Sicherheitsrichtlinien unerlässlich, um Knoten vor unbefugtem Zugriff zu schützen, wenn sensible Informationen gespeichert werden. Dieses EnvFiles-Feature vereinfacht die Erstellung von Anwendungen und ermöglicht neue Anwendungsfälle durch die Reduzierung komplexer Workarounds.

Kubernetes v1.34: Use An Init Container To Define App Environment Variables kubernetes.io

RSS Hunter • 10. Sept. 2025

Kubernetes v1.34: Snapshotfähiger API-Server-Cache

Kubernetes hat die Stabilität und Leistung des API-Servers erheblich verbessert, indem Probleme mit Listenanforderungen behoben wurden. Ein großer Fortschritt ist der Snapshottable-API-Server-Cache, der sich jetzt in v1.34 in der Beta-Phase befindet und es ermöglicht, die meisten Leseanforderungen direkt aus dem Speicher des API-Servers zu bedienen. Diese Funktion baut auf früheren Verbesserungen wie konsistenten Lesevorgängen aus dem Watch-Cache auf, der in v1.31 eingeführt wurde und es ermöglichte, gefilterte Sammlungen an etcd vorbeizuleiten. In v1.33 wurden Streaming-Encoder hinzugefügt, um große Antworten effizient zu verarbeiten, indem Elemente einzeln gesendet wurden, wodurch Speicher-Spitzen verhindert wurden. Der Snapshottable-Cache schließt die letzte Lücke, indem er historische LIST-Anforderungen, die häufig für die Paginierung verwendet werden, ebenfalls aus dem Cache bedienen kann. Dies geschieht durch die Erstellung von leichten, speichereffizienten Snapshots des Cache-Zustands für jedes Update. Wenn eine historische Anfrage eintrifft, ruft der API-Server den relevanten Snapshot ab und bedient die Daten direkt aus dem Speicher. Diese Synergie von Funktionen reduziert den Speicherbedarf des API-Servers und die Belastung von etcd drastisch. Folglich sind Kubernetes-Steuerungsebenen jetzt stabiler, skalierbarer und zuverlässiger. Die SnapshottableCache-Funktion ist in Kubernetes v1.34 standardmäßig aktiviert, sodass keine Benutzeraktion erforderlich ist, um von diesen Verbesserungen zu profitieren.

Kubernetes v1.34: Snapshottable API server cache kubernetes.io

RSS Hunter • 9. Sept. 2025

Kubernetes v1.34: VolumeAttributesClass für Volume-Modifikation GA

Die VolumeAttributesClass API hat in Kubernetes v1.34 die allgemeine Verfügbarkeit erreicht und ermöglicht die dynamische Änderung von Volume-Attributen. Diese clusterweite Ressource fungiert als Profil und ermöglicht Administratoren die Definition verschiedener Storage-QoS- oder Performance-Stufen. Benutzer wählen ein gewünschtes Profil über eine volumeAttributesClassName in ihrem PersistentVolumeClaim aus. Der Container Storage Interface (CSI) Driver wendet diese Änderungen dann auf das zugrunde liegende Speichersystem an. Dies erleichtert die dynamische Leistungsskalierung, die Kostenoptimierung durch Anpassungen im laufenden Betrieb und vereinfachte Operationen durch die Verwaltung von Änderungen innerhalb der Kubernetes-API. Die GA-Version führt die Abbruchunterstützung für nicht realisierbare Fehler ein, wodurch inkonsistente Volume-Zustände verhindert werden. Sie ermöglicht auch die Quoten-Durchsetzung für PVCs, die sich auf bestimmte VolumeAttributesClasses beziehen, mithilfe von ResourceQuota-Scope-Selektoren. Sowohl der Amazon EBS CSI Driver als auch der Google Compute Engine Persistent Disk CSI Driver unterstützen diese dynamischen Attributmodifikationen. Für weitere Fragen werden Benutzer an die SIG Storage Community verwiesen.

Kubernetes v1.34: VolumeAttributesClass for Volume Modification GA kubernetes.io

RSS Hunter • 8. Sept. 2025

Kubernetes v1.34: Pod-Ersatzrichtlinie für Jobs geht GA

Die Funktion zur Pod-Ersatzrichtlinie für Kubernetes-Jobs hat die allgemeine Verfügbarkeit erreicht. Standardmäßig ersetzen Jobs terminierende oder fehlgeschlagene Pods sofort, wodurch möglicherweise der Parallelismus überschritten wird. Dies kann Probleme für Anwendungen verursachen, die einzelne Instanzen pro Index erwarten, wie z. B. einige Machine-Learning-Frameworks. Es kann auch zu Verzögerungen bei der Planung, unnötiger Skalierung und vorübergehenden Quota-Umgehungen führen. Die neue Funktion ermöglicht es Benutzern, dieses Verhalten mit dem Feld .spec.podReplacementPolicy zu steuern. Die Richtlinie TerminatingOrFailed, die Standardeinstellung, erstellt Pods neu, sobald sie mit der Terminierung beginnen. Die Richtlinie Failed erstellt jedoch erst dann einen neuen Pod, wenn der alte vollständig terminiert wurde und sich in der Phase Failed befindet. Für Jobs mit einer Pod-Fehlerrichtlinie ist die Ersatzrichtlinie Failed obligatorisch. Der Status von terminierenden Pods kann mit kubectl get job myjob -o=jsonpath='{.status.terminating}' überprüft werden. Ein Beispiel zeigt, wie die Einstellung der Richtlinie auf Failed verhindert, dass ein neuer Pod gestartet wird, bis der terminierende Pod vollständig abgeschlossen ist. Diese Verbesserung zielt darauf ab, eine robustere Kontrolle über das Job-Pod-Lifecycle-Management zu ermöglichen.

Kubernetes v1.34: Pod Replacement Policy for Jobs Goes GA kubernetes.io

RSS Hunter • 5. Sept. 2025

PSI-Metriken für Kubernetes gehen in die Beta-Phase

Kubernetes v1.34 hat die Pressure Stall Information (PSI)-Metriken in den Beta-Status befördert und bietet damit ein wichtiges Werkzeug zur Überwachung des Node-Zustands in wachsenden Clustern. PSI, ein Linux-Kernel-Feature, quantifiziert den Ressourcendruck, indem es die Task-Stall-Zeit aufgrund von Engpässen misst, anstatt nur die Auslastung. Es liefert Metriken für CPU, Speicher und I/O, kategorisiert als "some" Pressure (mindestens eine Task angehalten) oder "full" Pressure (alle Nicht-Idle-Tasks angehalten). Diese Metriken sind über gleitende Fenster von 10 Sekunden, 1 Minute und 5 Minuten verfügbar. Das KubeletPSI-Feature-Gate ermöglicht dem Kubelet, PSI-Metriken über die Summary API und den /metrics/cadvisor Prometheus-Endpunkt zu erfassen und verfügbar zu machen. Neue Prometheus-Metriken wie container_pressure_cpu_stalled_seconds_total sind jetzt zugänglich. Diese Metriken helfen, Speicherlecks zu identifizieren, Ressourcenanforderungen zu optimieren und das Autoscaling auszulösen. Um PSI zu aktivieren, müssen Nodes den Linux-Kernel 4.20+ mit cgroup v2 ausführen und das KubeletPSI-Feature-Gate aktiviert sein. PSI-Metriken sind Linux-spezifisch und auf Windows-Nodes nicht verfügbar. Dieses Beta-Feature wird aktiv weiterentwickelt, und Feedback wird erwünscht.

PSI Metrics for Kubernetes Graduates to Beta kubernetes.io

RSS Hunter • 4. Sept. 2025

Kubernetes v1.34: Service Account Token Integration für Image Pulls geht in die Beta-Phase über

Kubernetes v1.34 fördert die Service-Konto-Token-Integration für Kubelet-Anmeldeinformationsanbieter auf Beta-Status. Diese Erweiterung ermöglicht es Anmeldeinformationsanbietern, werklastspezifische Service-Konto-Tokens für Registrierungsanmeldeinformationen zu verwenden und ersetzt damit langfristige Bildziehgeheimnisse. Die Beta-Version führt ein obligatorisches cacheType-Feld für Anmeldeinformationsanbieterkonfigurationen ein. Zwei Cachestrategien stehen zur Verfügung: Token für Anmeldeinformationen, die an die Token-Lebensdauer gebunden sind, und ServiceAccount für Anmeldeinformationen, die für alle Pods gültig sind, die dasselbe Service-Konto verwenden. Die Beta-Version bietet auch eine verbesserte Sicherheitsisolierung, die sicherstellt, dass Pods nur auf Bilder zugreifen können, die mit ihren autorisierten ServiceAccounts gezogen wurden. Dieses System verfolgt die ServiceAccount-Identität und überprüft sie, wenn ein Pod ein zwischengespeichertes Bild verwendet. Administratoren können den Bildzugriff widerrufen, indem sie ServiceAccounts löschen und neu erstellen. Die Funktion baut auf der Service-Konto-Node-Audience-Einschränkung für sichere Tokenanforderungen auf. Um die Beta-Funktion zu verwenden, stellen Sie sicher, dass Kubernetes v1.34 oder später verwendet wird und aktualisieren Sie die Anmeldeinformationsanbieter. Die Migration von Alpha erfordert das Hinzufügen des cacheType-Felds und die Überprüfung der Cachestrategien. Die Kubernetes-Community sucht nach Feedback zu dieser Funktion, insbesondere von Anmeldeinformationsanbieter-Implementierern. Weitere Entwicklungen und Feedback-Sammlungen sind für zukünftige Versionen geplant.

Kubernetes v1.34: Service Account Token Integration for Image Pulls Graduates to Beta kubernetes.io

RSS Hunter • 3. Sept. 2025

Kubernetes v1.34: Einführung der statischen Richtlinienoption CPU-Manager für die Ausrichtung des Uncore-Caches

"Kubernetes v1.34 führt die Beta-Funktion "prefer-align-cpus-by-uncorecache" für die statische Richtlinie des CPU-Managers ein. Diese Option optimiert Workloads auf Prozessoren mit geteilten Uncore-Cache-Architekturen. Der Uncore-Cache, auch bekannt als Last-Level-Cache, wird über CPU-Kerne hinweg gemeinsam genutzt. Moderne Prozessoren verwenden geteilte Uncore-Caches, um die Latenz zu reduzieren, indem sie den Cache unter den CPU-Gruppierungen aufteilen. Die Funktion ermöglicht es Kubernetes, Container-CPU innerhalb desselben Uncore-Caches zu platzieren, wodurch die Latenz und der Wettbewerb minimiert werden. Diese cache-bewusste Platzierung verbessert die Durchsatzrate für empfindliche Anwendungen. Standardmäßig verwendet Kubernetes eine gepackte Methode, die zu Problemen mit "lauten Nachbarn" und Cross-Cache-Latenz führen kann. Durch die Aktivierung dieser Funktion werden Container auf einzelne Caches isoliert, wodurch der Wettbewerb gelöst wird. Anwendungsfälle umfassen Telco-Anwendungen wie vRAN, aber die Vorteile hängen von der Workload ab, insbesondere für an Memory-Bandbreite gebundene Anwendungen. Um diese Funktion zu aktivieren, muss die CPU-Manager-Richtlinie auf "statisch" gesetzt und CPUManagerPolicyBetaOptions aktiviert werden. Die Konfiguration beinhaltet die Änderung der Kubelet-Konfigurationsdatei, um die Richtlinie und Optionen festzulegen. Die Funktion funktioniert auf Prozessoren mit monolithischem Uncore-Cache, indem sie eine Socket-Ausrichtung emuliert."

Kubernetes v1.34: Introducing CPU Manager Static Policy Option for Uncore Cache Alignment kubernetes.io

RSS Hunter • 2. Sept. 2025

Kubernetes v1.34: DRA ist jetzt allgemein verfügbar

"Kubernetes 1.34 bringt bedeutende Verbesserungen bei der dynamischen Ressourcenallokation (DRA). Die Kernfunktionalität von DRA hat den Status der allgemeinen Verfügbarkeit (General Availability – GA) erreicht, was bedeutet, dass sie stabil und für die langfristige Nutzung bereit ist. DRA ermöglicht eine flexible Verwaltung spezialisierter Hardware wie GPUs, indem es Workloads erlaubt, Geräteanforderungen zu spezifizieren und dem Scheduler die Zuweisung tatsächlicher Geräte überlässt. Mit der GA-Freigabe ist DRA standardmäßig aktiviert, ebenso wie zuvor im Beta-Stadium befindliche Funktionen.Mehrere Features sind in die Beta-Phase übergegangen. Dazu gehört das "Admin Access Labeling", mit dem autorisierte Benutzer die missbräuchliche Nutzung bestimmter Gerätefunktionen einschränken können. "Prioritized Lists" erlauben Workloads, mehrere akzeptable Gerätealternativen anzugeben, um eine flexiblere Planung zu ermöglichen. Die Kubelet-API wurde aktualisiert, um DRA-zugewiesene Pod-Ressourcen zu melden, was die Knotenüberwachung verbessert.Neue Alpha-Features geben einen Einblick in die Zukunft von DRA. "Extended Resource Mapping" unterstützt die Werbung von DRA-verwalteten Ressourcen als erweiterte Ressourcen, was die Nutzung für bestehende Workloads vereinfacht. "Consumable Capacity" führt eine flexible Gerätefreigabe ein, die es mehreren, nicht miteinander verbundenen Pods erlaubt, ein einzelnes physisches Gerät basierend auf vom Administrator definierten Richtlinien gemeinsam zu nutzen. "Binding Conditions" verbessern die Zuverlässigkeit der Planung, indem sie die Pod-Bindung verzögern, bis externe Ressourcen als bereit bestätigt sind. Schließlich verbessert der "Resource Health Status" für DRA die Beobachtbarkeit, indem er den Gerätezustand über den Pod-Status preisgibt. Das Team plant, weitere Alpha- und Beta-Features in zukünftigen Releases auf GA zu bringen."

Kubernetes v1.34: DRA has graduated to GA kubernetes.io

RSS Hunter • 1. Sept. 2025

Kubernetes v1.34: Feinere Kontrolle über Container-Neustarts

Kubernetes 1.34 führt ein Alpha-Feature namens Container-Neustart-Richtlinie und -Regeln ein. Dieses Feature ermöglicht die individuelle Steuerung von Container-Neustarten innerhalb eines Pods, wodurch die globale Neustart-Richtlinie des Pods überschrieben wird. Es ermöglicht auch bedingte Neustarte für Container basierend auf ihren Ausgangscode. Bisher teilten alle Container in einem Pod eine einzelne Neustart-Richtlinie. Diese Einschränkung verhinderte Szenarien wie das Ausführen eines Init-Containers, das nur einmal läuft, während der Hauptanwendungs-Container immer neu startet. Das neue Feature, das durch das Alpha-Feature-Gate ContainerRestartRules aktiviert wird, löst dieses Problem, indem es pro-Container-Neustart-Richtlinien und -Regeln ermöglicht. Anwendungsfälle umfassen Neustarte an Ort und Stelle für Trainingsjobs mit bestimmten Ausgangscodes, try-once-Init-Container und Pods mit mehreren Containern, die unterschiedliche Neustart-Anforderungen haben. Um dieses Feature zu verwenden, muss das ContainerRestartRules-Feature-Gate aktiviert werden. Beispiele zeigen, wie Neustarte basierend auf bestimmten Ausgangscodes konfiguriert, try-once-Init-Container implementiert und unterschiedliche Neustart-Richtlinien für mehrere Container zugewiesen werden können. Dieses Alpha-Feature begrüßt Community-Feedback und wird von SIG Node entwickelt. Zukünftige Pläne umfassen die Unterstützung für das Neustarten ganzer Pods.

Kubernetes v1.34: Finer-Grained Control Over Container Restarts kubernetes.io

RSS Hunter • 29. Aug. 2025

Kubernetes v1.34: Benutzerpräferenzen (kuberc) stehen für Tests in kubectl 1.34 zur Verfügung

Die Benutzereinstellungen für Kubectl erreichen in Kubernetes v1.34 die Beta-Phase und bieten Anpassungsoptionen. Diese Funktionalität ermöglicht es Benutzern, benutzerdefinierte Einstellungen für Kubectl-Befehle zu definieren. Eine Datei für Benutzereinstellungen, typischerweise mit dem Namen kuberc, befindet sich im Standard-Kubeconfig-Verzeichnis, $HOME/.kube. Diese Datei verwendet eine apiVersion und kind Struktur, ähnlich wie Kubernetes-Manifeste. Der defaults Abschnitt ermöglicht das Festlegen von Standardwerten für Kubectl-Befehlsoptionen, wie z. B. die immer interaktive Löschung. Diese Standardwerte können überschrieben werden, indem beim Ausführen von Befehlen explizit andere Optionen angegeben werden. Ein weiterer empfohlener Standard ist die Aktivierung von Server-Side Apply für Kubectl apply Befehle. Der aliases Abschnitt ermöglicht es Benutzern, Abkürzungen für häufig verwendete Befehle zu erstellen, was Zeit und Mühe spart. Aliase können so definiert werden, dass sie spezifischen Kubectl-Befehlen mit vordefinierten Argumenten und Optionen zugeordnet werden. Der Mechanismus unterstützt sowohl das Voranstellen als auch das Anhängen von Argumenten an den zugrunde liegenden Kubectl-Befehl. Debugging-Informationen für diese Funktion können mit erhöhter Ausführlichkeit abgerufen werden, z. B. mit -v=5. Benutzerfeedback wird dringend gewünscht, während die Funktion weiterentwickelt wird, und Benutzer können sich über Slack, GitHub Issues oder Community-Meetings beteiligen.

Kubernetes v1.34: User preferences (kuberc) are available for testing in kubectl 1.34 kubernetes.io

RSS Hunter • 28. Aug. 2025

Kubernetes v1.34: Von Wind und Wille (O' WaW)

Die Kubernetes v1.34-Veröffentlichung mit dem Motto "Of Wind & Will" (Von Wind und Wille) führt 58 Verbesserungen ein, von denen 23 in den stabilen Zustand übergehen. Dynamische Ressourcenallokation (DRA) für die Geräteverwaltung ist jetzt allgemein verfügbar und ermöglicht eine flexiblere Geräteauswahl und -konfiguration. Projizierte ServiceAccount-Tokens für kubelet Image-Credential-Provider bieten erhöhte Sicherheit durch die Verwendung kurzlebiger, arbeitslastspezifischer Tokens. Ein neues Ausgabeformat, KYAML, wird als Alpha-Funktion für kubectl eingeführt und zielt auf sichereres und eindeutigeres YAML für Kubernetes ab. Job-Controller verfügen nun über eine verzögerte Erstellung von Pods, um gleichzeitige Ausführung und Ressourcenkonflikte zu verhindern. Die Wiederherstellung von Fehlern bei der Volume-Erweiterung ist stabil und ermöglicht es Benutzern, Volume-Erweiterungen abzubrechen und erneut zu versuchen. VolumeAttributesClass ist ebenfalls stabil und bietet eine Kubernetes-native API zur Änderung von Volume-Parametern. Die strukturierte Authentifizierungskonfiguration ist nun stabil und verbessert die Verwaltbarkeit und Überprüfbarkeit der API-Server-Client-Authentifizierung. Eine feingranularere Autorisierung basierend auf Selektoren erhöht die Sicherheit und ermöglicht Regeln des geringsten Privilegs. Anonyme Anfragen können auf bestimmte Endpunkte beschränkt werden, was die Sicherheit verbessert, ohne externe Probes zu beeinträchtigen. Eine effizientere Wiederaufnahme für nicht planbare Pods reduziert unnötige Wiederholungsversuche und verbessert den Durchsatz der Planung. Die geordnete Löschung von Namespaces gewährleistet eine deterministische und sichere Entfernung von Ressourcen und mindert Sicherheitsrisiken. Streaming von Listenantworten verbessert die Skalierbarkeit, indem der Speicherbedarf des API-Servers reduziert wird. Eine robuste Initialisierung des Watch-Caches erhöht die Robustheit der Steuerungsebene, indem der Initialisierungsprozess des Watch-Caches widerstandsfähiger gegen Fehler gemacht wird.

Kubernetes v1.34: Of Wind & Will (O' WaW) kubernetes.io

RSS Hunter • 27. Aug. 2025

Optimierung von Linux Swap für Kubernetes: Eine eingehende Analyse

Das Kubernetes-Feature NodeSwap, das bald stabil werden soll, ermöglicht es Linux-Knoten, Swap-Speicher für zusätzliches virtuelles Speicher zu nutzen. Dies soll die Ressourcenauslastung verbessern und Out-of-Memory-(OOM)-Beendigungen reduzieren, wenn der physische RAM-Arbeitspeicher erschöpft ist. Die Wirksamkeit hängt jedoch von der Einstellung spezifischer Linux-Kernel-Parameter wie vm.swappiness, vm.min_free_kbytes und vm.watermark_scale_factor ab. Der Parameter vm.swappiness steuert die Präferenz des Kernels zwischen dem Austausch anonymen Speichers und der Rückgewinnung von dateibasiertem Speicher. vm.min_free_kbytes wirkt als Sicherheitspuffer und beeinflusst, wann aggressive Seitenrückgewinnung beginnt. vm.watermark_scale_factor passt den Abstand zwischen den freien Speicher-Wasserzeichen an, was den Austausch-Fenster beeinflusst. Tests haben gezeigt, dass die Standard-Kernel-Parameter zu OOM-Beendigungen und Neustarts von Knoten unter Speicherdruck führen können. Das Erhöhen von vm.min_free_kbytes und vm.watermark_scale_factor hat sich als entscheidend erwiesen, um vorzeitige Vertreibungen und OOM-Beendigungen zu vermeiden, indem dem Kernel mehr Zeit zum Austausch gegeben wird. Eine höhere Swappiness kann zu signifikanten I/O-Wartezeiten führen, während eine niedrigere Swappiness den Abwurf des Datei-Caches priorisiert. Die ordnungsgemäße Einstellung dieser Parameter zusammen mit den Vertreibungsschwellen des Kubelet erstellt eine ausgewogene Strategie für die Speicherdruckverwaltung. Risiken umfassen Leistungseinbußen aufgrund langsamer Swap-Zugriffe und die Maskierung von Speicherlecks.

Tuning Linux Swap for Kubernetes: A Deep Dive kubernetes.io

RSS Hunter • 19. Aug. 2025

Vorstellung des Headlamp-KI-Assistenten

Headlamp hat ein AI-Assistenten-Plugin zur Vereinfachung der Kubernetes-Verwaltung und Fehlerbehebung gestartet. Dieses Tool nutzt Large Language Models, um Benutzern zu ermöglichen, Fragen zu stellen und Befehle in natürlicher Sprache zu erteilen. Der AI-Assistent bietet schnelle Einblicke, die es Benutzern ermöglichen, den Cluster-Status zu verstehen und Probleme mit einfachen Abfragen zu diagnostizieren. Er bietet fokussierte und relevante Antworten basierend auf der aktuellen Ansicht des Benutzers innerhalb der Headlamp-Oberfläche. Darüber hinaus ist der Assistent handlungsorientiert und kann Aufgaben wie das Neustarten von Deployments mit Benutzerberechtigung ausführen. Die Integration nutzt den Kontext dessen, was der Benutzer gerade ansieht, um menschlich ähnliche Unterstützung anzubieten. Zum Beispiel kann er die Ursache eines fehlerhaften Pods identifizieren und Lösungen vorschlagen. Der Assistent enthält auch Unterstützung für ein Kubernetes-Tool, um Daten abzurufen und Aktionen auszuführen, ohne dass Ansichtswechsel erforderlich sind. Zukünftige Versionen planen, sich mit anderen Headlamp-Plug-ins zu integrieren, um umfassendere Einblicke in Bereiche wie GitOps und Überwachung zu erhalten. Benutzer können den AI-Assistenten aus dem Headlamp-Plugin-Katalog oder über sein Container-Image installieren. Die Entwickler bitten die Benutzer, die frühe Version auszuprobieren und Rückmeldung zu geben.

Introducing Headlamp AI Assistant kubernetes.io

RSS Hunter • 7. Aug. 2025

Vorschau auf Kubernetes v1.34

Kubernetes v1.34 ist für Ende August 2025 geplant. Diese kommende Version wird keine Entfernungen oder Veraltungen einführen, sondern zahlreiche Verbesserungen bieten. Ein wichtiger Höhepunkt ist die Zielsetzung der dynamischen Ressourcenzuweisung (DRA) für den stabilen Status. DRA bietet eine flexible Methode zum Verwalten von Geräten wie GPUs in Kubernetes-Clustern. Die ServiceAccount-Token-Integration für kubelet-Anmeldeinformationen soll den Beta-Status erreichen und die Authentifizierung für Bildziehungen vereinfachen. Ein neues Alpha-Feature für Deployments wird eine podReplacementPolicy einführen, um die Erstellung von Pods während von Aktualisierungen zu steuern. Die produktionsreife Ablaufverfolgung für den kubelet und den API-Server, die OpenTelemetry nutzt, soll den stabilen Status erreichen. Das trafficDistribution-Feld in Diensten wird die Werte PreferSameZone und PreferSameNode erreichen, die den Beta-Status anstreben. Ein neues Ausgabeformat, KYAML, ein sicherer Dialekt von YAML, der speziell für Kubernetes entwickelt wurde, wird für kubectl erwartet. Schließlich wird die fein abgestufte Autoskalierungskontrolle mit konfigurierbarer Toleranz für horizontale Pod-Autoscaler (HPAs) verbessert, die den Beta-Status erreichen soll.

Kubernetes v1.34 Sneak Peek kubernetes.io

RSS Hunter • 28. Juli 2025

Post-Quanten-Kryptographie in Kubernetes

Post-Quanten-Kryptographie (PQC) ist eine Antwort auf die Bedrohung durch Quantencomputer, die aktuelle kryptografische Standards brechen könnten. PQC-Algorithmen sind so konzipiert, dass sie sowohl gegen Angriffe von klassischen als auch von Quantencomputern sicher sind. Die Industrie arbeitet daran, PQC-Algorithmen zu standardisieren und einzuführen, wobei der erste standardisierte Algorithmus der Module-Lattice Key Encapsulation Mechanism (ML-KEM) ist. Der Übergang zu PQC-Standards wird voraussichtlich zwischen 2030 und 2035 stattfinden. In TLS sind der Schlüsselaustausch und digitale Signaturen zwei Hauptkryptographieoperationen, die gesichert werden müssen, wobei der Schlüsselaustausch aufgrund des Angriffsrisikos eine höhere Priorität hat. Hybride Schlüsselaustauschmechanismen, die klassische und PQC-Algorithmen kombinieren, werden zur Sicherung des Schlüsselaustauschs eingesetzt. Die Unterstützung für PQC-Schlüsselaustauschmechanismen verbessert sich im gesamten Ökosystem rapide, wobei Go, Browser, OpenSSL und Apple die Unterstützung für das ML-KEM-basierte hybride Schema hinzufügen. Kubernetes v1.33, das Go 1.24 verwendet, unterstützt standardmäßig den hybriden Post-Quanten-X25519MLKEM768 für TLS-Verbindungen, was einen wichtigen Schritt darstellt, um Kubernetes quantensicher zu machen. Es gibt jedoch noch Einschränkungen und potenzielle Fallstricke, wie z. B. Inkompatibilitäten bei Go-Versionen und Probleme mit Paketgrößen, die angegangen werden müssen. PQC-digitale Signaturen befinden sich noch in den frühen Phasen der Entwicklung und Einführung, wobei Herausforderungen wie größere Schlüssel- und Signaturgrößen, Leistungsprobleme und eingeschränkte Toolchain-Unterstützung bestehen.

Post-Quantum Cryptography in Kubernetes kubernetes.io

RSS Hunter • 18. Juli 2025

Fehlerbehebung in Pods mit Geräten navigieren

Kubernetes steht bei der Verwaltung von Ausfällen spezieller Hardware in AI/ML-Workloads vor Herausforderungen. Diese Workloads setzen stark auf GPUs und andere Beschleuniger und Ausfälle haben einen erheblichen Einfluss auf die Leistung. Das bestehende Kubernetes-Modell geht von statischen Ressourcen aus und bietet keine robuste Unterstützung für Hardware-Ausfälle. AI/ML-Workloads, einschließlich Training und Inferenz, unterscheiden sich erheblich von traditionellen Anwendungen hinsichtlich ihrer Ressourcenbedürfnisse und Ausfallfolgen. Trainingsjobs sind ressourcenintensiv und erfordern koordinierte Neustarts bei Ausfällen, während Inferenz-Aufgaben kontinuierlichen Betrieb erfordern. Die bestehenden Kubernetes-Annahmen, wie die einfache Ressourcenersatzung und einfache Pod-Skalierung, sind für diese komplexen Szenarien unzureichend. Trotz dieser Herausforderungen bleibt Kubernetes die bevorzugte Plattform aufgrund ihrer Reife und Ökosystems. Aktuelle Lösungen umfassen manuelle Workarounds wie benutzerdefinierte Health-Controller und Pod-Watcher, um Geräteausfälle zu verwalten. Diese Lösungen haben Einschränkungen und erfordern privilegierten Zugriff, was die Notwendigkeit für verbesserte native Kubernetes-Unterstützung hervorhebt. Das Kubernetes-Projekt arbeitet aktiv daran, die Verarbeitung von Geräteausfällen zu verbessern, um eine bessere Zuverlässigkeit und Ressourcenverwaltung zu erreichen.

Navigating Failures in Pods With Devices kubernetes.io

RSS Hunter • 3. Juli 2025

Bildkompatibilität in cloudbasierten Umgebungen

In Branchen wie Telekommunikation und Hochleistungsrechnen benötigen containerisierte Anwendungen spezifische Betriebssystemkonfigurationen oder Hardware-Präsenz. Trotz der Open Container Initiative (OCI) gab es eine Lücke bei der Ausdruck von Kompatibilitätsanforderungen. Das Kubernetes-Projekt Node Feature Discovery (NFD) löst dieses Problem, indem es Hardware- und Systemmerkmale von Cluster-Knoten erkennt und meldet. NFD hilft bei der Planung von Workloads auf Knoten, die spezifische Systemanforderungen erfüllen, was für Anwendungen mit strengen Hardware- oder Betriebssystem-Abhängigkeiten entscheidend ist. Container-Images, die auf Basis-Images aufbauen, können Kompatibilitätsprobleme mit dem Host-Betriebssystem haben, die sich in Abhängigkeiten von Treibern, Bibliotheken, Kernel-Modulen oder Funktionen manifestieren. Die Definition von Kompatibilität kann sich auf andere Container-Technologien und OCI-Artefakte erstrecken. Die Arbeitsgruppe Image Compatibility zielt darauf ab, einen Standard für Kompatibilitäts-Metadaten in Container-Images einzuführen, damit Container-Autoren erforderliche Host-Betriebssystem-Funktionen deklarieren können. Die Spezifikation, die in Kubernetes Node Feature Discovery implementiert ist, definiert eine strukturierte Möglichkeit, Kompatibilität in OCI-Image-Manifesten auszudrücken. Die Lösung integriert Kompatibilitäts-Metadaten in Kubernetes, ermöglicht intelligente Planung und Workload-Optimierung. Die Übernahme von Kompatibilitäts-Metadaten wird die Zuverlässigkeit und Leistung spezieller containerisierter Anwendungen verbessern.

Image Compatibility In Cloud Native Environments kubernetes.io

RSS Hunter • 25. Juni 2025

Änderungen an Kubernetes Slack

Der Kubernetes-Slack wird seinen Sonderstatus verlieren und wird am 20. Juni in einen standardmäßigen kostenlosen Slack umgewandelt. Später in diesem Jahr wird unsere Gemeinschaft wahrscheinlich zu einer neuen Plattform wechseln. Wenn Sie für einen Kanal oder einen privaten Kanal verantwortlich sind oder Mitglied einer Benutzergruppe sind, müssen Sie einige Aktionen so schnell wie möglich ausführen.Im letzten Jahrzehnt hat Slack unseren Projekt mit einem kostenlosen benutzerdefinierten Enterprise-Konto unterstützt. Sie haben uns mitgeteilt, dass sie dies nicht länger tun können, da unser Slack einer der größten und aktivsten auf der Plattform ist. Daher werden sie ihn auf einen standardmäßigen kostenlosen Slack herabstufen, während wir andere Optionen entscheiden und implementieren.Am Freitag, den 20. Juni, werden wir den Funktionsbeschränkungen unterliegen. Die primären, die uns betreffen werden, sind die Begrenzung auf 90 Tage Historie und die Deaktivierung mehrerer Apps und Workflows, die wir derzeit verwenden. Das Slack-Admin-Team wird sein Bestes tun, um diese Beschränkungen zu managen.Verantwortliche Kanalbesitzer, Mitglieder privater Kanäle und Mitglieder von Benutzergruppen sollten einige Aktionen ausführen, um sich auf das Upgrade vorzubereiten und zu erhalten, so schnell wie möglich.Das CNCF-Projektpersonal hat vorgeschlagen, dass unsere Gemeinschaft nach Discord migrieren sollte. Da wir die Grenzen von Slack bereits überschritten haben, haben sie bereits untersucht, wie ein Kubernetes-Discord aussehen würde. Discord würde es uns ermöglichen, neue Tools und Integrationen zu implementieren, die der Gemeinschaft helfen würden, wie z.B. die Synchronisierung von GitHub-Gruppenmitgliedschaften. Der Lenkungsausschuss diskutieren und entscheiden über unsere zukünftige Plattform.Bitte sehen Sie unsere FAQ und überprüfen Sie die Mailingliste kubernetes-dev und den #announcements-Kanal für weitere Nachrichten. Wenn Sie spezifisches Feedback zu unserem Slack-Status haben, beteiligen Sie sich an der Diskussion auf GitHub.

Changes to Kubernetes Slack kubernetes.io

RSS Hunter • 16. Juni 2025

Erweiterung der Ereignisverwaltung in Kubernetes durch benutzerdefinierte Aggregation

Kubernetes-Ereignisse bieten wertvolle Einblicke in Cluster-Operationen, aber das Management und die Analyse werden herausfordernd, wenn Cluster wachsen. Die Herausforderungen umfassen das Ereignisvolumen, die begrenzte Aufbewahrung, den Mangel an Korrelation, Klassifizierung und Aggregation. Ein benutzerdefiniertes Ereignis-Aggregations-System kann Ingenieur-Teams helfen, das Cluster-Verhalten besser zu verstehen und Probleme effektiver zu beheben. Das System besteht aus drei Hauptkomponenten: einem Ereignis-Beobachter, einem Ereignis-Prozessor und einem Speicher-Backend. Der Ereignis-Beobachter überwacht die Kubernetes-API auf neue Ereignisse, der Ereignis-Prozessor verarbeitet, kategorisiert und korreliert Ereignisse, und das Speicher-Backend speichert verarbeitete Ereignisse für eine längere Aufbewahrung. Der Ereignis-Prozessor bereichert Ereignisse mit zusätzlichem Kontext und Klassifizierung, und das Speicher-Backend unterstützt effiziente Abfragen großer Ereignisvolumina, flexible Aufbewahrungsrichtlinien und Unterstützung für Aggregationsabfragen. Die Implementierung guter Praktiken für Ereignis-Management, wie Ressourceneffizienz, Skalierbarkeit und Zuverlässigkeit, ist entscheidend. Erweiterte Funktionen wie Mustererkennung und Echtzeit-Benachrichtigungen können implementiert werden, um wiederkehrende Probleme zu identifizieren und darauf effektiver zu reagieren. Ein gut konzipiertes Ereignis-Aggregations-System kann die Cluster-Beobachtbarkeit und die Fehlersuche-Fähigkeiten erheblich verbessern, und zukünftige Verbesserungen könnten die Verwendung von Machine-Learning für Anomalie-Erkennung, die Integration mit beliebten Beobachtungsplattformen und benutzerdefinierte Ereignis-APIs für anwendungsspezifische Ereignisse umfassen.

Enhancing Kubernetes Event Management with Custom Aggregation kubernetes.io

RSS Hunter • 10. Juni 2025

Einführung der Gateway API Inference Extension

Die Gateway API Inference Extension (Erweiterung für Inferenz) adressiert Routing-Herausforderungen in Kubernetes, die durch langlaufende, ressourcenintensive Inferenz-Sitzungen mit großen Sprachmodellen (LLMs) entstehen. Traditionelle Load Balancer sind für diese komplexen Workloads unzureichend. Diese Erweiterung verbessert die bestehende Gateway API mit inferenzspezifischen Fähigkeiten. Sie führt zwei benutzerdefinierte Ressourcen (Custom Resources) ein: InferencePool, das Model-Server-Pods verwaltet, und InferenceModel, das benutzerseitige Modell-Endpunkte definiert. Der Request-Flow umfasst Gateway-Routing, eine Endpoint Selection Extension (Erweiterung zur Endpunktauswahl) für die optimale Pod-Auswahl und inferenzfähiges Scheduling. Dies führt zu verbessertem modellbasiertem Routing. Benchmarking zeigt einen vergleichbaren Durchsatz wie bei Standard-Kubernetes-Diensten, aber eine deutlich geringere Latenz, insbesondere bei höheren Abfrageraten. Zukünftige Entwicklungen umfassen Funktionen wie Prefix-Cache-fähiges Load Balancing und Unterstützung für verschiedene Modelltypen und Beschleuniger. Die Erweiterung vereinfacht und standardisiert das AI/ML-Traffic-Routing innerhalb von Kubernetes. Sie zielt darauf ab, die Effizienz und User Experience bei der Bereitstellung und Verwaltung von LLM-Diensten zu verbessern.

Introducing Gateway API Inference Extension kubernetes.io

RSS Hunter • 5. Juni 2025

Sidecar zuerst starten: Wie man Fallstricke vermeidet

Dieser Blogbeitrag untersucht, wie man sicherstellt, dass ein Kubernetes Sidecar-Container startet und bereit wird, bevor der Hauptanwendungscontainer startet. Native Sidecar-Container in Kubernetes starten vor der Hauptanwendung, oft fast gleichzeitig, was nicht immer erwünscht ist. Der Autor untersucht Readiness Probes, Startup Probes und PostStart Lifecycle Hooks, um den Start der Hauptanwendung zu verzögern, bis der Sidecar bereit ist. Die Verwendung einer Readiness Probe allein verzögert den Start der Hauptanwendung nicht. Eine Startup Probe, korrekt konfiguriert, verzögert die Hauptanwendung effektiv, bis der Sidecar bereit ist. Der Beitrag erwähnt auch kurz PostStart Hooks als eine Option. Liveness Probes starten hauptsächlich den Sidecar neu und beeinflussen nicht die Bereitschaft der Hauptanwendung. Die wichtigste Erkenntnis ist, dass eine Startup Probe die effektivste Methode ist, um den Start der Hauptanwendung zu verzögern. Der Autor schließt mit der Betonung, wie wichtig es ist, die Container-Startreihenfolge zu steuern, wenn die Hauptanwendung von einem Sidecar abhängt. Dies bietet eine Lösung, wenn eine Modifizierung des Anwendungscodes nicht möglich ist.

Start Sidecar First: How To Avoid Snags kubernetes.io

RSS Hunter • 3. Juni 2025

Gateway API v1.3.0: Fortschritte bei Request Mirroring, CORS, Gateway Merging und Retry Budgets

Die Gateway API v1.3.0, veröffentlicht am 24. April 2025, führt prozentbasierte Request-Mirroring im Standard-Kanal ein. Diese Funktion ermöglicht das Spiegeln einer Teilmenge von Anfragen, was für Dienste mit hohem Volumen nützlich ist. Die Version fügt außerdem experimentelle Funktionen hinzu, darunter CORS-Filterung, ein standardisierter Mechanismus für Listener- und Gateway-Zusammenführung (XListenerSets) und Retry-Budgets (XBackendTrafficPolicy). Ressourcen des experimentellen Kanals verwenden jetzt die API-Gruppe gateway.networking.x-k8s.io und enthalten ein "X"-Präfix. Die CORS-Filterung ermöglicht die Konfiguration von Cross-Origin-Anfragen mit dem neuen "CORS"-Filter. XListenerSets ermöglichen gemeinsame Listener und Gateway-Zusammenführung, wodurch die Listener-Verwaltung verbessert wird. Mit Retry-Budgets können Benutzer Retry-Limits mithilfe der XBackendTrafficPolicy konfigurieren. Die API ist kompatibel mit Kubernetes 1.26 oder höher. Mehrere Implementierungen sind bereits konform mit den neuen Funktionen. Die Community ermutigt zur Beteiligung an der Gestaltung der Zukunft der Kubernetes Routing APIs.

Gateway API v1.3.0: Advancements in Request Mirroring, CORS, Gateway Merging, and Retry Budgets kubernetes.io

RSS Hunter • 2. Juni 2025

Kubernetes v1.33: Größenänderung von Pods vor Ort erreicht Beta-Status

Das Kubernetes-Projekt hat bekannt gegeben, dass das Feature zur Platzierung von Pods in situ auf Beta-Status hochgestuft wurde und standardmäßig in der Kubernetes-Version 1.33 aktiviert sein wird. Dieses Feature ermöglicht es Benutzern, die CPU- und Speicherressourcen, die einem Container zugewiesen sind, ohne Neustart des Containers zu ändern. Die Platzierung von Pods in situ entscheidet sich für mehrere Schlüsselvorteile bei der vertikalen Skalierung, einschließlich reduzierter Störungen, verbesserter Ressourcenauslastung und schnellerer Skalierung. Das Feature hat seit seiner Alpha-Version bedeutende Änderungen erfahren, einschließlich der Einführung eines Resize-Subressourcen, des Resize-Status über Bedingungen und der Unterstützung von Sidecars. Die Stabilität und Zuverlässigkeit des Features wurden durch die Verfeinerung der zugewiesenen Ressourcenmanagement, die Verbesserung des Checkpointing und des Status-Trackings und die schnellere Erkennung von Resize-Vorgängen verbessert. Die Community konzentriert sich auf die nächsten Schritte, einschließlich der Stabilität und Produktion, der Beseitigung von Einschränkungen und der Integration mit VerticalPodAutoscaler. Benutzer können bereits mit der Platzierung von Pods in situ experimentieren, wenn das Feature standardmäßig aktiviert ist. Rückmeldung ist entscheidend, und Benutzer können Probleme melden oder ihre Erfahrungen über GitHub-Issues, Mailinglisten und Slack teilen. Die vollständigen, tiefgreifenden Design-Details finden sich in der KEP-1287: In-place-Update von Pod-Ressourcen. Die Kubernetes-Community freut sich darauf, wie Benutzer die Platzierung von Pods in situ nutzen, um effizientere und resilientere Anwendungen zu erstellen.

Kubernetes v1.33: In-Place Pod Resize Graduated to Beta kubernetes.io

RSS Hunter • 16. Mai 2025

Etcd v3.6.0 angekündigt

Das etcd-Team hat Version 3.6.0 veröffentlicht, die erste Minor-Release seit Version 3.5.0, welche neue Funktionen einführt, Fortschritte bei den langjährigen Bemühungen um Downgrade-Unterstützung und die Migration zu v3store macht und zahlreiche kritische und wichtige Probleme behebt. Diese Veröffentlichung beinhaltet auch wesentliche Optimierungen in der Speichernutzung, wodurch Effizienz und Leistung verbessert werden. Etcd ist Kubernetes als SIG beigetreten, was dem Projekt ermöglicht, seine Nachhaltigkeit zu verbessern. Systematische Robustheitstests wurden eingeführt, um Korrektheit und Zuverlässigkeit zu gewährleisten. Die etcd-Operator-Arbeitsgruppe plant, die Benutzerfreundlichkeit zu verbessern. Der v2store wurde eingestellt und v3store ist zur alleinigen Quelle der Wahrheit für Mitgliedsdaten geworden. Etcd v3.6.0 ist die erste Version, die Downgrade vollständig unterstützt, und der Prozess beinhaltet die Migration des Daten-Schemas zur Zielversion, gefolgt von einem Rolling Downgrade. Die Veröffentlichung führt auch Feature-Gates im Kubernetes-Stil zur Verwaltung neuer Funktionen ein und unterstützt die Endpunkte /livez und /readyz, was sich an den Liveness- und Readiness-Probes von Kubernetes orientiert. Die Veröffentlichung hat zudem die Speichernutzung um mindestens 50% verbessert und eine durchschnittliche Leistungsverbesserung von etwa 10% sowohl beim Lese- als auch beim Schreib-Durchsatz erzielt.

Announcing etcd v3.6.0 kubernetes.io

RSS Hunter • 16. Mai 2025

Kubernetes 1.33: Die Erfolgspolitik für Jobs wird allgemein verfügbar

Das Kubernetes-Projekt hat bekannt gegeben, dass die Erfolgspolitik für Jobs in der Version v1.33 allgemein verfügbar ist. Bei Batch-Workloads möchten Benutzer möglicherweise einen Job als erfolgreich markieren, selbst wenn einige Nachfolger fehlschlagen. Die Erfolgspolitik für Jobs ermöglicht es Benutzern, frühzeitige Austrittskriterien über das .spec.successPolicy-Feld anzugeben. Dieses Feld ist besonders wertvoll für wissenschaftliche Simulationen, KI/ML- und Hochleistungsrechnen- Batch-Workloads. Benutzer können ein minimales erforderliches Größe von erfolgreichem Index für einen Job als erfolgreich markiert angeben. Sobald ein Job die Erfolgspolitik erfüllt, wird er als erfolgreich markiert und alle Pods werden beendet. Die Erfolgspolitik kann angepasst werden, um ein bestimmtes Index oder eine bestimmte Anzahl von Indexen anzugeben, die erfolgreich sein müssen, damit der Job als erfolgreich markiert wird. Der Job-Controller fügt einen SuccessCriteriaMet-Zustand zum Job-Status hinzu, sobald der Job die Erfolgspolitik erreicht, und initiiert dann die Bereinigung und Beendigung der Pods. Der Job erhält einen Complete-Zustand, wenn die Bereinigung und Beendigung abgeschlossen sind.

Kubernetes 1.33: Job's SuccessPolicy Goes GA kubernetes.io

RSS Hunter • 15. Mai 2025

Kubernetes v1.33: Aktualisierungen des Container-Lebenszyklus

Kubernetes v1.33 führt Aktualisierungen für den Lebenszyklus von Containern ein, einschließlich der Unterstützung einer Null-Schlafdauer in Container-Lifecycle-Hooks. Die in v1.29 eingeführte Sleep-Aktion ermöglicht es Containern, nach dem Start oder vor der Beendigung für eine bestimmte Zeit anzuhalten. Ursprünglich unterstützte die Sleep-Aktion keine Null-Schlafdauer, aber diese wurde in v1.32 hinzugefügt und ist nun in v1.33 standardmäßig aktiviert. Kubernetes v1.33 führt auch Alpha-Unterstützung für die Anpassung des Stopp-Signals ein, das an Container gesendet wird, wenn sie beendet werden. Dies ermöglicht es Benutzern, ein benutzerdefiniertes Stopp-Signal in der Container-Spec anzugeben, das als neuer Lifecycle-Handler der API hinzugefügt wird. Die Konfiguration des Stopp-Signals wird durchgesetzt, um sicherzustellen, dass sie für den Knoten gültig ist, auf dem der Pod geplant ist. Wenn kein benutzerdefiniertes Stopp-Signal definiert ist, greift die Container-Runtime auf das im Container-Image definierte Stopp-Signal oder das Standardsignal der Runtime zurück. Die Funktion erfordert, dass sowohl Kubernetes als auch die Container-Runtime Container-Stopp-Signale unterstützen, was noch in Arbeit ist. Um die Funktion zu aktivieren, müssen Benutzer das Feature-Gate sowohl im kube-apiserver als auch im kubelet einschalten. Das SIG-Node-Team treibt diese Funktion voran und freut sich über Feedback, Teilnahme und Engagement aus der Community.

Kubernetes v1.33: Updates to Container Lifecycle kubernetes.io

RSS Hunter • 14. Mai 2025

Kubernetes v1.33: Begrenzung für Zurücksetzen pro Index für Jobs wird allgemein verfügbar

"In Kubernetes v1.33 hat das Feature "Backoff-Limit pro Index" die allgemeine Verfügbarkeit erreicht. Dieses Feature ermöglicht es Benutzern, die Anzahl der Wiederholungen pro Index zu steuern. Zuvor war das Feld "spec.backoffLimit" nicht flexibel genug für Workloads, bei denen jeder Index als unabhängig betrachtet wird. Das Feature "Backoff-Limit pro Index" beseitigt diese Einschränkung, indem es die Anzahl der tolerierten Pod-Fehler pro Index spezifiziert. Das Feld "spec.backoffLimitPerIndex" wird verwendet, um die Anzahl der tolerierten Pod-Fehler pro Index anzugeben. Darüber hinaus können Benutzer die Fehlerbehandlung feinjustieren, indem sie eine Obergrenze für die Gesamtzahl der fehlgeschlagenen Indizes definieren und einen Kurzschluss definieren, um einen fehlgeschlagenen Index zu erkennen. Wenn die Anzahl der tolerierten Fehler überschritten wird, wird der Index als fehlgeschlagen markiert und in dem Feld "Job's status.failedIndexes" aufgeführt. Ein Beispiel für eine Job-Spezifikation zeigt, wie das Feature "Backoff-Limit pro Index" mit dem Feature "Pod-Fehler-Richtlinie" kombiniert werden kann. Das Feature wurde von der Kubernetes-Arbeitsgruppe für Batch-Verarbeitung und der SIG-Apps-Community gesponsert. Benutzer, die an neuen Features arbeiten möchten, können sich für den Kanal anmelden und regelmäßige Community-Treffen besuchen."

Kubernetes v1.33: Job's Backoff Limit Per Index Goes GA kubernetes.io

RSS Hunter • 13. Mai 2025

Kubernetes v1.33: Die Image-Pull-Policy funktioniert endlich so, wie Sie es immer erwartet haben!

Die imagePullPolicy in Kubernetes weist ein überraschendes Verhalten auf, das seit über 10 Jahren ein Problem darstellt und es Pods ermöglicht, auf authentifizierte Images ohne Anmeldeinformationen zuzugreifen. Die IfNotPresent-Policy ermöglichte es einem Pod, ein bereits auf einem Knoten vorhandenes Image zu verwenden, selbst wenn er keine Anmeldeinformationen zum Abrufen des Images bereitstellte. Dies ist ein Sicherheitsproblem, da Pods ohne Anmeldeinformationen auf private Images zugreifen können. In Kubernetes v1.33 wurde die IfNotPresent-Policy aktualisiert, um sicherzustellen, dass Pods Anmeldeinformationen bereitstellen müssen, um ein zuvor abgerufenes privates Image zu verwenden. Der Kubelet überprüft die Anmeldeinformationen des Pods, bevor er ihm erlaubt, das Image zu verwenden. Die Option imagePullPolicy: Never ruft keine Images ab, erfordert aber Anmeldeinformationen, um ein bereits vorhandenes Image zu verwenden. Die Option imagePullPolicy: Always hat immer wie beabsichtigt funktioniert und erfordert eine Authentifizierung für jede Image-Anforderung. Das neue Feature verwendet persistente, dateibasierte Caches auf jedem Knoten, um die Anmeldeinformationen des Pods zu überprüfen. Das Feature basiert auf der Aufzeichnung der Absicht, ein Image abzurufen, der Extraktion von Anmeldeinformationen und der Erstellung eines Datensatzes erfolgreicher Abrufe. Das Feature ist in Kubernetes v1.33 verfügbar und kann durch Aktivieren des Feature Gate KubeletEnsureSecretPulledImages aktiviert werden.

Kubernetes v1.33: Image Pull Policy the way you always thought it worked! kubernetes.io

RSS Hunter • 12. Mai 2025

Kubernetes v1.33: Streaming-List-Antworten

Die Verwaltung der Stabilität von Kubernetes-Clustern ist entscheidend, wenn die Infrastruktur wächst, und das Handling großer Listenanforderungen kann die Stabilität des Clusters beeinträchtigen. Die Kubernetes-Community hat die Streaming-Codierung für Listenantworten eingeführt, um das Problem des unnötigen Speicherverbrauchs bei großen Ressourcen anzugehen. Aktuelle API-Antwortencodierer speichern die gesamte Antwortdaten als einen einzelnen Puffer, was die inkrementelle Freigabe von Speicher während der Übertragung verhindert. Dieser Ansatz wird ineffizient bei großem Maßstab, was zu hohem und langanhaltendem Speicherverbrauch im kube-apiserver-Prozess führt. Die encoding/json-Paket und Protocol Buffers haben Einschränkungen bei der Verarbeitung großer Datensätze, was die Notwendigkeit von streaming-basierten Ansätzen hervorhebt Streaming-Encoder verarbeitet und überträgt jedes Element einzeln, was es ermöglicht, den Speicher schrittweise freizugeben, während Frames oder Chunks übertragen werden. Dieser Ansatz reduziert den Speicheraufwand, der vom API-Server benötigt wird, und hält den Speicherverbrauch vorhersehbar und handhabbar. Der Streaming-Encoder ist rückwärts kompatibel, garantierend byte-für-byte-Konsistenz mit dem ursprünglichen Encoder, und unterstützt alle Kubernetes-Listentypen ohne clientseitige Änderungen erforderlich. Die Einführung der Streaming-Codierung hat zu signifikanten Leistungsverbesserungen geführt, einschließlich reduziertem Speicherverbrauch, verbesserter Skalierbarkeit und erhöhter Stabilität. Benchmark-Ergebnisse haben eine 20-fache Verbesserung des Speicherverbrauchs gezeigt, reduziert von 70-80 GB auf 3 GB, was die Wirksamkeit des neuen Streaming-Codiermechanismus demonstriert.

Kubernetes v1.33: Streaming List responses kubernetes.io

RSS Hunter • 9. Mai 2025

Kubernetes 1.33: Volume Populatoren erreichen allgemeine Verfügbarkeit (GA)

Kubernetes-Volume-Populatoren sind jetzt allgemein verfügbar, was Benutzern ermöglicht, jede benutzerdefinierte Ressource als Datenquelle einer PersistentVolumeClaim anzugeben. Das Feature-Gate AnyVolumeDataSource wird für Version 1.33 von Kubernetes behandelt, als wäre es immer aktiviert. Die dataSourceRef in PVC ermöglicht es Benutzern, eine benutzerdefinierte Ressource als Datenquelle anzugeben. Es gibt vier Hauptverbesserungen gegenüber der Beta-Version, darunter die Optionalität des Populator-Pods, die Einführung von plugin-basierten Funktionen, die Hinzufügung von Mutator-Funktionen zur Änderung von Kubernetes-Ressourcen und die Bereitstellung flexibler Metrik-Verarbeitung für Anbieter. Die GA-Version verbessert auch den Populator, um die Löschung temporärer Ressourcen zu unterstützen, wenn das ursprüngliche PVC gelöscht wird. Um es auszuprobieren, können Benutzer den Schritten im vorherigen Beta-Blog folgen. Das Kubernetes-SIG-Speicher sucht nach Rückmeldung zu potenziellen Funktionserweiterungen, einschließlich Multi-Sync, bidirektionalem Sync, Daten-Population mit Prioritäten und Daten-Population aus mehreren Quellen.

Kubernetes 1.33: Volume Populators Graduate to GA kubernetes.io

RSS Hunter • 8. Mai 2025

Kubernetes v1.33: Von Secrets zu Service Accounts: Die Entwicklung des Kubernetes Image-Pull-Vorgangs

Kubernetes hat sich weiterentwickelt, um seine Abhängigkeit von langlebigen Anmeldeinformationen, die in der API gespeichert sind, zu verringern. Ein bemerkenswertes Beispiel ist die Umstellung von Kubernetes Service Account Tokens von statischen auf ephemere Tokens mit OpenID Connect-kompatibler Semantik. Eine große Lücke besteht jedoch weiterhin bei der Authentifizierung für das Pullen von Images, wo Kubernetes-Cluster derzeit auf langlebige Image-Pull-Secrets oder kubelet-Credential-Provider auf Knotenebene angewiesen sind. Dies birgt Sicherheits- und betriebliche Herausforderungen, da Image-Pull-Secrets schwer zu rotieren sind und eine Kompromittierung zu unbefugtem Zugriff auf Images führen kann. Um dieses Problem anzugehen, führt Kubernetes die Service Account Token Integration für Kubelet Credential Providers ein, die es Credential-Providern ermöglicht, pod-spezifische Service Account Tokens zu verwenden, um Registry-Anmeldeinformationen zu erhalten. Diese Verbesserung beseitigt die Notwendigkeit von langlebigen Image-Pull-Secrets und bietet Workload-spezifische Authentifizierung, ephemere Anmeldeinformationen und eine nahtlose Integration mit bestehenden Kubernetes-Authentifizierungsmechanismen. Der neue Ansatz ermöglicht es kubelet-Credential-Providern, Workload Identity zu verwenden, wenn sie Image-Registry-Anmeldeinformationen abrufen, was Vorteile wie Sicherheit, granulare Zugriffskontrolle und betriebliche Einfachheit bietet. Das Feature ist derzeit in Alpha verfügbar und soll in Beta für Kubernetes v1.34 ausgeliefert werden. Die weitere Entwicklung konzentriert sich auf die Implementierung von Caching-Mechanismen und die Verbesserung der Flexibilität für Credential-Provider. Benutzer können das Feature ausprobieren, indem sie das Feature-Gate ServiceAccountTokenForKubeletCredentialProviders aktivieren und ihren Credential-Provider so modifizieren, dass er Service Account Tokens für die Authentifizierung verwendet. Die Kubernetes-Community freut sich über Feedback und ermutigt Benutzer, sich über den SIG Auth-Kanal auf Kubernetes Slack an der Entwicklung dieses Features zu beteiligen.

Kubernetes v1.33: From Secrets to Service Accounts: Kubernetes Image Pulls Evolved kubernetes.io

RSS Hunter • 7. Mai 2025

Kubernetes v1.33: Feingranulare Steuerung von SupplementalGroups wird Beta

Kubernetes hat eine neue Funktion namens supplementalGroupsPolicy eingeführt, die eine präzisere Steuerung von Supplemental Groups in Containern ermöglicht und so die Sicherheitslage und Transparenz von UID/GID-Details verbessert. Diese Funktion ist in Kubernetes v1.33 von Alpha zu Beta übergegangen. Die Funktion ermöglicht die Implementierung einer präziseren Steuerung von Supplemental Groups in Containern, insbesondere beim Zugriff auf Volumes. Standardmäßig führt Kubernetes Gruppeninformationen aus dem Pod mit Informationen zusammen, die in /etc/group im Container-Image definiert sind, was zu Sicherheitsrisiken führen kann. Das Feld supplementalGroupsPolicy im Sicherheitskontext des Pods ermöglicht die Steuerung, wie Kubernetes ergänzende Gruppen für Containerprozesse innerhalb eines Pods berechnet. Die Strict-Richtlinie ignoriert Gruppenmitgliedschaften, die in /etc/group für den primären Benutzer des Containers definiert sind, und stellt sicher, dass nur die angegebenen Gruppen-IDs als Supplemental Groups an die Containerprozesse angehängt werden. Diese Funktion macht auch die Prozessidentität, die an den ersten Containerprozess des Containers angehängt ist, über das Feld .status.containerStatuses[].user.linux verfügbar. Die supplementalGroupsPolicy beeinflusst nur die anfängliche Prozessidentität, und ein Container mit ausreichenden Berechtigungen kann seine Prozessidentität ändern. Die Strict-Richtlinie erfordert eine CRI-Laufzeitumgebung, die diese Funktion unterstützt, z. B. containerd v2.0 oder höher und CRI-O v1.31 oder höher.

Kubernetes v1.33: Fine-grained SupplementalGroups Control Graduates to Beta kubernetes.io

RSS Hunter • 6. Mai 2025

Kubernetes v1.33: Verhindern von PersistentVolume-Leaks bei der Löschung in falscher Reihenfolge wird GA

"Kubernetes v1.33 hat ein Feature zur Vermeidung von PersistentVolume-Lecks bei der Löschung in der falschen Reihenfolge zur allgemeinen Verfügbarkeit (General Availability, GA) befördert. Es stellt sicher, dass Speicherressourcen ordnungsgemäß freigegeben werden, um unerwünschte Lecks zu vermeiden. In früheren Kubernetes-Versionen verhinderte das Löschen eines PersistentVolumes (PV) vor seinem gebundenen PersistentVolumeClaim (PVC), dass die Konfigurationsrichtlinie für die Rückgewinnung von Ressourcen (Reclaim-Policy) beachtet wurde. Dies führte dazu, dass das zugehörige Speicher-Asset in der externen Infrastruktur nicht entfernt wurde. Mit Kubernetes v1.33 ist dieses Problem jetzt behoben, und die konfigurierte Lösch-Rückgewinnungsrichtlinie wird zuverlässig beachtet, selbst wenn PVs vor ihren gebundenen PVCs gelöscht werden. Dies wird durch die Verwendung von Finalizern erreicht, die sicherstellen, dass der Speicher-Backend die zugewiesene Speicherressource wie beabsichtigt freigibt. Bei CSI-Volumes) wird ein Finalizer für neue und bestehende PVs hinzugefügt, der nur entfernt wird, nachdem der Speicher vom Backend gelöscht wurde. Das Feature gilt nicht für statisch bereitgestellte in-Tree-Plugin-Volumes. Um das neue Verhalten nutzen zu können, müssen Benutzer ihr Cluster auf Kubernetes v1.33 upgraden und die CSI-External-Provisioner-Version 5.0.1 oder höher ausführen. Die Kubernetes-Speicher-Spezial-Gruppe (SIG) begrüßt neue Mitwirkende, die sich am Design und der Entwicklung von CSI oder irgendeinem Teil des Kubernetes-Speichersystems beteiligen möchten.

Kubernetes v1.33: Prevent PersistentVolume Leaks When Deleting out of Order graduates to GA kubernetes.io

RSS Hunter • 5. Mai 2025

Kubernetes v1.33: Änderbarer CSI-Knoten-Zuweisungszählung

Kubernetes v1.33 führt ein Alpha-Feature namens mutable CSI-Knoten zuweisbare Anzahl ein, das es CSI-Treibern ermöglicht, die maximale Anzahl von Volumes, die ein Knoten verarbeiten kann, dynamisch zu aktualisieren. Dieses Feature verbessert die Genauigkeit von Pod-Planungsentscheidungen und reduziert Planungsfehler. Traditionell melden CSI-Treiber eine statische maximale Volumen-Anbindungsgrenze, die sich während des Lebenszyklus eines Knotens aufgrund verschiedener Gründe ändern kann. Die statische Meldung kann dazu führen, dass Kubernetes Pods auf Knoten plant, die scheinbar Kapazität haben, was zu Pods im ContainerCreating-Zustand führt. Mit dem neuen Feature-Gate MutableCSINodeAllocatableCount ermöglicht Kubernetes CSI-Treibern, Knoten-Anbindungskapazitäten bei Laufzeit anzupassen und zu melden. Dies stellt sicher, dass der Planer die aktuellste, genaueste Ansicht der Knoten-Kapazität hat. Das Feature unterstützt zwei Mechanismen für die Aktualisierung der gemeldeten Knoten-Volumen-Grenzen: periodische Aktualisierungen und reaktive Aktualisierungen. Um dieses Alpha-Feature zu verwenden, müssen Sie das MutableCSINodeAllocatableCount-Feature-Gate in den kube-apiserver- und kubelet-Komponenten aktivieren. Die Kubernetes-Community begrüßt Feedback zu diesem Feature und ermutigt zum Testen und zur Diskussion, um seine Evolution hin zu Beta- und GA-Stabilität zu fördern.

Kubernetes v1.33: Mutable CSI Node Allocatable Count kubernetes.io

RSS Hunter • 2. Mai 2025

Kubernetes v1.33: Neue Funktionen in DRA

"Die dynamische Ressourcenzuweisung (DRA) in Kubernetes nähert sich der allgemeinen Verfügbarkeit und ist für Kubernetes v1.34 geplant. Ursprünglich war DRA ein Alpha-Feature in v1.26, wurde für v1.31 neu entworfen und erreichte den Beta-Status in v1.32. DRA bietet eine robustere und anpassungsfähigerequest-API im Vergleich zum Device-Plugin. In der v1.33-Veröffentlichung wird der Status der Treiber-eigenen Ressourcenanforderung auf Beta hochgestuft, was ermöglicht, dass Treiber spezifische Gerätestatusmeldungen senden können. Neue Alpha-Features in v1.33 umfassen partitionierbare Geräte für die On-Demand-Partitionierung, Geräte-Makel und -Toleranzen für die Kennzeichnung der Geräteverfügbarkeit und die Priorisierte Liste für die Angabe von alternativen Gerätepräferenzen. Der Admin-Zugriff wurde verfeinert, indem die Erstellung von ResourceClaim-Objekten mit dem adminAccess-Feld auf autorisierte Benutzer beschränkt wird. Eine neue v1beta2-API vereinfacht die Benutzererfahrung vor und bereitet zukünftige Features vor. Verbesserte RBAC-Regeln und nahtlose Treiber-Updates sind auch enthalten. Das v1.34-Roadmap zielt auf die allgemeine Verfügbarkeit von DRA zu erreichen, indem es standardmäßig auf allen v1.34-Clustern aktiviert wird. Alpha-Features aus v1.33 sind für die Beta-Beförderung in v1.34 geplant. Die Community-Beteiligung wird durch den WG-Geräte-Management-Slack-Kanal und -Meetings gefördert.

Kubernetes v1.33: New features in DRA kubernetes.io

RSS Hunter • 1. Mai 2025

Kubernetes v1.33: Speicher-Kapazitätsbewertung von Knoten für dynamische Bereitstellung (Alpha)

Kubernetes v1.33 führt StorageCapacityScoring ein, ein Alpha-Feature für topology-bewusste Volume-Bereitstellung. Dieses Feature ermöglicht die Planung von Pods basierend auf der Knotenspeicherkapazität, wobei Knoten mit der meisten oder wenigsten verfügbaren Speicherplatz priorisiert werden. Zuvor war nur das Filtern von Knoten mit unzureichender Kapazität möglich, was Scheduler-Erweiterungen für kapazitätsbasierte Planung erforderte. StorageCapacityScoring bietet Vorteile für die lokale PV-Bereitstellung auf Knoten, indem PVs Knoten mit ausreichendem Speicherplatz für zukünftige Erweiterungen zugewiesen werden. Es erleichtert auch die Kostenreduzierung durch maximale Auslastung von Ressourcen und das sequenzielle Füllen von Knoten in Cloud-Umgebungen. Um dieses Feature zu aktivieren, setzen Sie StorageCapacityScoring=true in den Feature-Gates des Kube-Schedulers. Der VolumeBinding-Plugin-Parameter shape konfiguriert die Prioritäten von Knoten basierend auf der Speicherauslastung. Standardmäßig werden Knoten mit höherer verfügbarer Kapazität priorisiert, aber dies kann umgekehrt werden. Dieses neue Feature ersetzt das veraltete VolumeCapacityPriority-Alpha-Feature, das Knoten mit niedriger verfügbarer Kapazität während der statischen Bereitstellung priorisierte. Die Dokumentation bietet weitere Details und Konfigurationsbeispiele. Weitere Informationen finden Sie in KEP-4049.

Kubernetes v1.33: Storage Capacity Scoring of Nodes for Dynamic Provisioning (alpha) kubernetes.io

RSS Hunter • 30. Apr. 2025

Kubernetes v1.33: Image Volumes werden in den Beta-Status überführt!

Kubernetes Image Volumes, eingeführt als Alpha-Version in v1.31, wechselt in v1.33 zur Beta-Version. Die Funktion ist standardmäßig deaktiviert, da die Unterstützung durch die Container-Laufzeiten begrenzt ist. CRI-O v1.31 bietet erste Unterstützung, die Beta-Unterstützung kommt in v1.33, während die Alpha-Unterstützung für containerd in v2.1.0 erscheint, wobei die Beta-Version in Arbeit ist. Wichtige Verbesserungen in der Beta-Version umfassen die Unterstützung von subPath und subPathExpr für das schreibgeschützte Mounten bestimmter Unterverzeichnisse im Image. Nicht existierende Unterverzeichnisse können nicht gemountet werden, und Kubernetes validiert die Pfade zur Sicherheit. Laufzeiten müssen die Pfade ebenfalls verifizieren und Fehler über Kubelet-Ereignisse melden. Drei neue Kubelet-Metriken verfolgen Image-Volume-Anforderungen, erfolgreiche Mounts und Mount-Fehler. Benutzer können subPath oder subPathExpr innerhalb von volumeMounts angeben, um vorhandene Unterverzeichnisse zu mounten. Ein Beispiel demonstriert das Mounten eines Unterverzeichnisses namens dir innerhalb eines Pods. Dieser Blog-Beitrag feiert den Wechsel der Funktion zur Beta-Version, würdigt die Mitwirkenden und ermutigt zu Feedback über Slack oder die SIG Node Mailingliste. Weiterführende Lektüre zu Verwendung von Image Volumes mit Pods und eine Übersicht über Image Volumes sind verfügbar.

Kubernetes v1.33: Image Volumes graduate to beta! kubernetes.io

RSS Hunter • 29. Apr. 2025

Kubernetes v1.33: Konfigurierbare Toleranz für HorizontalPodAutoscaler

Kubernetes 1.33 führt eine konfigurierbare Toleranz für die horizontale Pod-Autoskalierung (HPA) ein, eine Alpha-Funktion, die ein angepasstes Skalierungsverhalten ermöglicht. HPA passt die Replikatzahlen automatisch basierend auf der Ressourcenauslastung an und zielt auf einen Zielwert ab, z. B. 75 % CPU-Auslastung. Bisher verhinderte eine feste Toleranz von 10 % ein Skalieren aufgrund kleiner Metrik-Schwankungen. Dieser clusterweite Standardwert von 10 % erwies sich für große Deployments oft als zu grob. Die neue Funktion ermöglicht die Festlegung der Toleranz unter spec.behavior.scaleDown und spec.behavior.scaleUp innerhalb des HorizontalPodAutoscaler-Objekts. Dies ermöglicht unterschiedliche Toleranzen für das Hoch- und Herunterskalieren und bietet eine feinere Steuerung. Ein typischer Anwendungsfall ist die Einstellung einer niedrigeren Toleranz für das Hochskalieren, um eine schnelle Reaktion auf Spitzen zu gewährleisten, während eine höhere Toleranz für das Herunterskalieren häufige Anpassungen der Replikate verhindert. Um diese Funktionalität nutzen zu können, muss das Feature-Gate HPAConfigurableTolerance aktiviert werden. Eine Beispielkonfiguration zeigt eine Toleranz von 5 % beim Herunterskalieren und 0 % beim Hochskalieren. Weitere technische Details finden Sie in KEP-4951; Issue 4951 verfolgt den Fortschritt des Features in Richtung allgemeiner Verfügbarkeit.

Kubernetes v1.33: HorizontalPodAutoscaler Configurable Tolerance kubernetes.io

RSS Hunter • 28. Apr. 2025

Kubernetes v1.33: Benutzer-Namespaces standardmäßig aktiviert!

Kubernetes v1.33 aktiviert jetzt standardmäßig Benutzer-Namespaces, was die Sicherheit von Pods verbessert. Benutzer-Namespaces, ein Linux-Kernel-Feature, das sich von Kubernetes-Namespaces unterscheidet, isolieren Container-UIDs und -GIDs vom Host. Diese Isolation verhindert laterale Bewegungen zwischen Containern und erhöht die Sicherheit des Hosts, selbst wenn ein Container entkommt. Das Aktivieren von Benutzer-Namespaces ermöglicht das Ausführen von Anwendungen, die privilegierte Operationen erfordern, ohne dem Host vollständigen Root-Zugriff zu gewähren. Pods können sich für Benutzer-Namespaces anmelden, indem sie hostUsers: false in der Pod-Spezifikation setzen. Die Funktionalität erfordert Dateisysteme, die idmap-Mounts unterstützen, ein Linux-Kernel-Feature, das die UID/GID-Zuordnung vereinfacht. Während eine Kernel-Version 6.3 oder höher für vollständige Unterstützung empfohlen wird, können ältere Kernel-Versionen mit Einschränkungen funktionieren. Benutzer-Namespaces mildern zahlreiche CVEs, indem sie Root-Privilegien auf dem Host verhindern, selbst wenn ein Container kompromittiert wird. Dies verbessert die Sicherheit erheblich, indem es den Auswirkungen von Container-Entweichen einschränkt und den Gesamtschutz des Systems erhöht. Weitere Informationen und Ressourcen sind verfügbar, um ein tieferes Verständnis und die Implementierung zu ermöglichen.

Kubernetes v1.33: User Namespaces enabled by default! kubernetes.io

RSS Hunter • 25. Apr. 2025

Fortsetzung des Übergangs von Endpunkten zu EndpointSlices

"Die Kubernetes-Endpunkte-API ist ab Version 1.33 als veraltet markiert, mit Warnungen bei ihrer Verwendung, da EndpointSlices mehr Funktionen anbieten. Neue Service-Funktionen wie Dual-Stack-Netzwerke werden nur von EndpointSlices unterstützt. Der Plan ist, die Anforderung, dass Cluster den Endpoints-Controller ausführen müssen, schließlich zu entfernen. Benutzer mit bestehenden Endpoints-API-Workloads sollten zu EndpointSlices migrieren. Im Gegensatz zu Endpoints kann ein Service mehrere EndpointSlices haben, insbesondere für Dual-Stack-Netzwerke oder wenn mehr als 100 Endpunkte überschritten werden. EndpointSlices werden nach Etikett abgerufen, nicht nach Namen, unter Verwendung von "kubernetes.io/service-name". Die Generierung von EndpointSlices erfordert die Verwendung des neuen API-Typs und die Organisation von Informationen auf andere Weise. EndpointSlices erfordern eine explizite Adresstyp-Deklaration (IPv4 oder IPv6). Jedes Adressen-Array in einem EndpointSlice enthält konventionell ein einzelnes Element. Die EndpointSlice-API bietet Bedingungen wie "ready: false" für Endpunkte und unterstützt Topologie-Hinweise."

Continuing the transition from Endpoints to EndpointSlices kubernetes.io

RSS Hunter • 24. Apr. 2025