Jag_cz - stock.adobe.com
So konfigurieren Sie die Kubernetes Garbage Collection
Die Garbage Collection von Kubernetes ist eine Aufgabe für den Cluster-Zustand. Erfahren Sie, wie Sie Garbage Collections konfigurieren, um Bereitstellungen effektiv zu verwalten.
Die Garbage Collection sorgt für den Erhalt des Zustands von Kubernetes-Clustern. Admins sollten die Best Practices für die Konfiguration der Garbage Collection anwenden und die richtigen Untersuchungen durchführen, um zu entscheiden, ob sie den standardmäßigen, automatischen Prozess zur Bereinigung von Workloads verwenden oder die Einstellungen für die Garbage Collection selbst manuell konfigurieren sollten.
Die oberste Komponente von Kubernetes ist ein Cluster, in dem Knoten gruppiert sind, um Pods auszuführen. Die zugrunde liegende Container-Images ändern sich, wenn neue Anwendungsversionen bereitgestellt werden. Kubernetes beendet ältere Pods, wenn die Pods, die neue Anwendungsversionen enthalten, bereitgestellt werden.
Garbage Collection bezieht sich auf Mechanismen, die Cluster-Ressourcen für Kubernetes bereinigen, was für den Zustand eines Clusters wichtig ist. Die Garbage Collection kann Ressourcen wie beendete Pods, abgeschlossene Jobs, ungenutzte Container und mehr aufräumen.
Konfiguration für die Garbage Collection
Es gibt mehrere Konfigurationen, mit denen Unternehmen die Kontrolle über die Garbage Collection erlangen können.
Felder der Metadaten
Kubernetes verwendet ein sogenanntes Metadatenfeld, um zu verfolgen, welche Ressourcen zu anderen übergeordneten Ressourcen gehören. Wenn eine übergeordnete Ressource gelöscht wird, kann Kubernetes alle zugehörigen Ressourcen bereinigen.
Beispielsweise gehört einem Deployment ein ReplicaSet, dem die Pods in diesem ReplicaSet gehören. Wenn ein Deployment von einem Administrator oder einem anderen Tool außerhalb von K8s gelöscht wird, werden daher auch das ReplicaSet und die Pods per Referenz gelöscht.
Es ist möglich, dieses Verhalten zu ändern, indem das Feld auf true gesetzt wird. Wenn es auf true gesetzt ist, bleiben die Ressourcen unberührt, nachdem eine übergeordnete Ressource entfernt wurde.
Images
Standardmäßig löscht das Kubelet, das auf jedem Knoten läuft, unbenutzte Images alle zwei Minuten. Um diese Einstellungen zu konfigurieren, verwenden Sie eine Kubelet-Konfigurationsdatei und geben Sie einen Dauerwert für das Feld an.
Um die Garbage Collection von Images auszulösen, berücksichtigt das Kubelet die Festplattennutzung. Verwenden Sie die beiden konfigurierbaren Felder HighThresholdPercent und LowThresholdPercent, um Bilder auf der Grundlage ihrer letzten Verwendung zu entfernen. Das Kubelet beginnt mit den ältesten Bildern, wenn der Speicherplatz den in HighThresholdPercent eingestellten Wert erreicht. Bis der in LowThresholdPercent eingestellte Wert erreicht ist, wird Kubelet weiterhin Images löschen.
Container
Nicht verwendete Container werden alle fünf Minuten aufgeräumt. Steuern Sie das spezifische Verhalten einer Bereinigung mit den Flags --maximum-dead-containers, --maximum-dead-containers-per-container und --minimum-container-ttl-duration.
--maximum-dead-containers legt global die maximale Anzahl von Containern fest, die erhalten bleiben sollen, bevor die Garbage Collection gestoppte Container entfernt oder löscht. Beim Start von Kubelet ist dieser Wert standardmäßig auf -1 gesetzt oder kann von Administratoren manuell gesetzt werden. Das bedeutet, dass es keine Begrenzung für die Anzahl der gestoppten Container in einem Cluster gibt, bevor die Garbage Collection ausgelöst wird.
--maximum-dead-containers-per-container legt die Anzahl der alten Container-Instanzen fest, die pro Container aufbewahrt werden sollen. Der Standardwert für diesen Wert ist auf 1 gesetzt. --minimum-container-ttl-duration steuert die Zeitdauer, bevor eine Container Garbage Collection ausgelöst wird. Dieser Wert ist auf 0 gesetzt, was bedeutet, dass diese Einstellung standardmäßig deaktiviert ist.
Kubernetes Jobs
Nachdem ein Kubernetes Job beendet wurde, bleiben der abgeschlossene Job und der Pod bestehen, es sei denn, andere Bedingungen für die Garbage Collection werden standardmäßig ausgelöst. Wenn beispielsweise die Einstellung terminated-pod-gc-threshold des Kube-Controller-Managers ausgelöst wird, gibt es eine begrenzte Anzahl von beendeten Pods, bevor die Garbage Collection beginnt, Pods zu löschen. In den meisten Fällen werden die beendeten Pods noch eine Weile im System verbleiben, da der Standardwert auf 12.500 Pods festgelegt ist.
Setzen Sie das .spec.ttlSecondsAfterFinished-Feld des Jobs, um dieses Verhalten zu steuern. Dieses Feld bestimmt, wie viele Sekunden nach Beendigung des Jobs vergehen, bevor der TTL-Controller den Auftrag löscht. Es wird empfohlen, dieses Feld zu verwenden, da die Alternative die Standardlöschpolitik von orphanDependents ist. Mit orphanDependents werden Pods, die von Jobs gestartet werden, verwaist, nachdem der Job abgeschlossen ist. Das kann zu Leistungseinbußen führen, wenn sich mehrere verwaiste Pods ansammeln. Setzen Sie einen Wert, um sicherzustellen, dass die Pods nach Beendigung eines Jobs gelöscht werden.
Finalizer
Um Kubernetes mitzuteilen, dass vor dem Löschen von Ressourcen bestimmte Aktionen durchgeführt werden sollen, erstellen Sie eine Ressource mit einer Manifestdatei und setzen Sie das Feld metadata.finalizers.
Der Finalizer ist ähnlich wie die Annotationen. Das eigentlich wichtige ist der Controller, der den Finalizer verwaltet. Wenn man zum Beispiel ein PersistentVolume verwendet, wird oft ein Finalizer von kubernetes.io/pv-protection verwendet. Dadurch wird verhindert, dass das PersistentVolume gelöscht wird, entweder durch einen Administrator oder einen automatisierten Prozess, der den Pod löscht, bevor der Finalizer entfernt wird. In einem Szenario, in dem ein Pod ein PersistentVolume verwendet, das gelöscht wird, wird die Ressource als Beendigung markiert, kann aber nicht gelöscht werden, bis der Finalizer-Schlüssel kubernetes.io/pv-protection entfernt wird. Der PersistentVolume-Controller wird den Finalizer erst löschen, wenn der Pod das PersistentVolume nicht mehr verwendet, wodurch der Controller das PersistentVolume löschen kann.
