04 Juni 2026

Wie funktioniert Kubernetes-Garbage-Collection?

Kubernetes Garbage Collection ist ein automatisierter Prozess, der nicht mehr benötigte Ressourcen und Objekte im Cluster identifiziert und löscht. Dieser Mechanismus verhindert, dass verwaiste Container-Images, beendete Pods und ungenutzte Volumes unnötig Speicherplatz belegen und die Cluster-Performance beeinträchtigen.

Unkontrollierter Speicherverbrauch gefährdet Ihre Cluster-Stabilität

Ohne effektive Garbage Collection sammeln sich in Kubernetes-Clustern schnell Hunderte von verwaisten Container-Images, beendeten Pods und ungenutzten Volumes an. Diese Ressourcenanhäufung führt zu Speicherengpässen auf den Nodes, verlangsamten Deployments und im schlimmsten Fall zu kompletten Cluster-Ausfällen. Sie können diesem Problem vorbeugen, indem Sie die Garbage-Collection-Parameter gezielt an Ihre Workload-Muster anpassen und regelmäßige Monitoring-Routinen etablieren.

Fehlende GC-Konfiguration kostet Sie wertvolle Entwicklungszeit

Standardmäßig arbeitet Kubernetes Garbage Collection mit konservativen Einstellungen, die für Produktionsumgebungen oft ungeeignet sind. Dies führt dazu, dass Ihre Entwicklerteams kostbare Zeit mit manueller Bereinigung verbringen, anstatt sich auf die Anwendungsentwicklung zu konzentrieren. Durch eine proaktive Konfiguration der GC-Policies können Sie diese Wartungsarbeiten automatisieren und Ihre Teams für strategisch wichtigere Aufgaben freistellen.

Was ist Kubernetes Garbage Collection und warum ist sie wichtig?

Kubernetes Garbage Collection ist ein integrierter Mechanismus, der automatisch nicht mehr referenzierte Objekte im Cluster erkennt und entfernt. Sie verhindert Speicherprobleme, optimiert die Ressourcennutzung und sorgt für einen sauberen Cluster-Zustand ohne manuelle Eingriffe.

Die Garbage Collection arbeitet nach dem Prinzip der Besitzverhältnisse zwischen Kubernetes-Objekten. Jedes Objekt kann Owner-Referenzen auf andere Objekte haben. Wenn ein Owner-Objekt gelöscht wird, markiert der Garbage Collector alle abhängigen Objekte zur Löschung. Dieser Prozess läuft kontinuierlich im Hintergrund und stellt sicher, dass keine verwaisten Ressourcen im Cluster verbleiben.

Besonders in dynamischen Umgebungen mit häufigen Deployments und Updates ist eine funktionierende Garbage Collection entscheidend. Ohne sie würden sich schnell große Mengen an ungenutzten Container-Images, beendeten Pods und temporären Volumes ansammeln, die letztendlich die Cluster-Performance und -Stabilität gefährden könnten.

Wie funktioniert der Garbage Collection-Prozess in Kubernetes?

Der Kubernetes Garbage Collector verwendet Owner-Referenzen zwischen Objekten, um Abhängigkeiten zu verfolgen. Wenn ein Owner-Objekt gelöscht wird, werden alle abhängigen Objekte automatisch zur Bereinigung markiert und anschließend entfernt.

Der Prozess läuft in mehreren Phasen ab: Zunächst scannt der Garbage Collector alle Objekte im Cluster und analysiert deren Owner-Referenzen. Objekte ohne gültige Owner werden als verwaist identifiziert. Anschließend prüft der Controller, ob diese Objekte tatsächlich gelöscht werden können, ohne andere Systemkomponenten zu beeinträchtigen.

Kubernetes unterscheidet zwischen verschiedenen Löschstrategien. Bei der „Foreground Deletion“ werden abhängige Objekte zuerst gelöscht, bevor das Owner-Objekt entfernt wird. Die „Background Deletion“ löscht das Owner-Objekt sofort und kümmert sich danach um die Abhängigkeiten. Die „Orphan Deletion“ entfernt nur die Owner-Referenzen, lässt aber die abhängigen Objekte bestehen.

Welche Kubernetes-Objekte werden automatisch bereinigt?

Kubernetes bereinigt automatisch Pods, ReplicaSets, Services, ConfigMaps, Secrets und andere Objekte mit Owner-Referenzen. Container-Images und Volumes werden basierend auf konfigurierbaren Schwellenwerten und Nutzungsmustern entfernt.

Zu den häufig bereinigten Objekten gehören beendete Pods, die ihre Lifecycle-Phase abgeschlossen haben. Diese werden standardmäßig nach einer bestimmten Zeit automatisch entfernt, um Speicherplatz freizugeben. ReplicaSets, die nicht mehr von Deployments referenziert werden, fallen ebenfalls unter die automatische Bereinigung.

Container-Images unterliegen einer speziellen Bereinigungslogik. Der kubelet auf jedem Node überwacht den verfügbaren Speicherplatz und entfernt ungenutzte Images, wenn definierte Schwellenwerte erreicht werden. Dabei werden Images nach ihrem letzten Verwendungszeitpunkt priorisiert. Volumes werden bereinigt, wenn ihre zugehörigen Pods gelöscht werden und keine anderen Claims mehr bestehen.

Wie kann man Garbage Collection in Kubernetes konfigurieren?

Sie konfigurieren Kubernetes Garbage Collection über kubelet-Parameter für Container-Images, kube-controller-manager-Einstellungen für Objekte und spezifische Annotations für individuelle Ressourcen. Die wichtigsten Parameter sind imageGCHighThreshold, imageGCLowThreshold und terminatedPodGCThreshold.

Für die Image-Bereinigung können Sie die Parameter imageGCHighThreshold und imageGCLowThreshold in der kubelet-Konfiguration anpassen. Der High-Threshold definiert den Speicherverbrauch, ab dem die Bereinigung startet, während der Low-Threshold das Ziel der Bereinigung festlegt. Typische Werte liegen bei 85% und 80%.

Die Bereinigung beendeter Pods steuern Sie über den terminatedPodGCThreshold im kube-controller-manager. Dieser Parameter bestimmt, wie viele beendete Pods pro Node aufbewahrt werden, bevor die Garbage Collection einsetzt. Für individuelle Objekte können Sie das Verhalten über Annotations wie „kubernetes.io/gc“ beeinflussen und bestimmte Ressourcen von der automatischen Bereinigung ausschließen.

Welche Probleme können bei der Kubernetes Garbage Collection auftreten?

Häufige Probleme sind unvollständige Owner-Referenzen, die zu verwaisten Objekten führen, aggressive GC-Einstellungen, die aktive Ressourcen löschen, und Performance-Probleme bei großen Clustern mit vielen Objekten.

Ein typisches Problem entsteht durch fehlerhafte oder fehlende Owner-Referenzen in benutzerdefinierten Objekten. Wenn diese Referenzen nicht korrekt gesetzt sind, können Objekte entweder nicht bereinigt werden oder versehentlich gelöscht werden, obwohl sie noch benötigt werden. Dies führt zu inkonsistenten Cluster-Zuständen und schwer nachvollziehbaren Fehlern.

Performance-Probleme treten besonders in großen Clustern auf, wenn der Garbage Collector zu viele Objekte gleichzeitig verarbeiten muss. Dies kann zu hoher CPU-Last auf den Control-Plane-Nodes führen und andere Kubernetes-Operationen verlangsamen. Zu aggressive Bereinigungseinstellungen können außerdem dazu führen, dass Container-Images gelöscht werden, die kurz darauf wieder benötigt werden, was unnötige Download-Zeiten verursacht.

Wie credativ® bei der Kubernetes-Verwaltung unterstützt

Als spezialisiertes Open Source-Beratungsunternehmen unterstützen wir Sie bei der optimalen Konfiguration und Verwaltung Ihrer Kubernetes-Umgebungen. Unser erfahrenes Team hilft Ihnen dabei, Garbage-Collection-Strategien zu entwickeln, die perfekt auf Ihre spezifischen Anforderungen zugeschnitten sind.

Unsere Kubernetes-Expertise umfasst:

  • Analyse und Optimierung bestehender GC-Konfigurationen
  • Entwicklung maßgeschneiderter Bereinigungsstrategien
  • Monitoring und Alerting für Speicherverbrauch
  • Troubleshooting bei GC-bedingten Performance-Problemen
  • Schulungen für Ihr Entwicklungsteam

Profitieren Sie von unserem 24/7-Support und unserer langjährigen Erfahrung im Open Source-Bereich. Kontaktieren Sie uns für eine unverbindliche Beratung zu Ihren Kubernetes-Herausforderungen und erfahren Sie, wie wir Ihre Container-Infrastruktur optimieren können.

Ähnliche Artikel

Kategorien: credativ® Inside

über den Autor

Peter Dreuw

Head of Sales & Marketing

zur Person

Peter Dreuw arbeitet seit 2016 für die credativ GmbH und ist seit 2017 Teamleiter. Seit 2021 ist er Teil des Management-Teams als VP Services der Instaclustr. Mit der Übernahme durch die NetApp wurde seine neue Rolle "Senior Manager Open Source Professional Services". Im Rahmen der Ausgründung wurde er Mitglied der Geschäftsleitung als Prokurist. Sein Aufgabenfeld ist die Leitung des Vertriebs und des Marketings. Er ist Linux-Nutzer der ersten Stunden und betreibt Linux-Systeme seit Kernel 0.97. Trotz umfangreicher Erfahrung im operativen Bereich ist er leidenschaftlicher Softwareentwickler und kennt sich auch mit hardwarenahen Systemen gut aus.

Beiträge ansehen


Beitrag teilen: