Comment nettoyer les anciennes tâches Kubernetes
Les tâches Kubernetes créent des pods à plusieurs reprises jusqu’à ce qu’un nombre spécifié de conteneurs se terminent avec succès. Les Jobs sont souvent utilisés avec le mécanisme CronJob de niveau supérieur qui démarre automatiquement de nouveaux Jobs selon un calendrier récurrent.
L’utilisation régulière de Jobs et de CronJobs entraîne généralement la présence d’un grand nombre d’objets dans votre cluster. Les tâches et leurs pods sont intentionnellement conservés indéfiniment après leur achèvement. Cela vous permet d’inspecter l’état du travail et de récupérer ses journaux à l’avenir. Cependant, trop de tâches terminées polluent la sortie de Kubectl lorsque vous exécutez des commandes telles que kubectl get pods ou kubectl get jobs. Cela peut rendre plus difficile la concentration sur une activité pertinente.
Dans cet article, nous partagerons quelques méthodes pour nettoyer les anciens travaux. Vous pourrez supprimer les objets redondants de votre cluster, automatiquement ou à la demande.
Sommaire
Limites de conservation de l’historique des tâches cron
Le nettoyage automatique est pris en charge pour les Jobs créés par un CronJob depuis Kubernetes v1.6. Cette méthode vous permet de configurer des seuils de suppression distincts pour les Jobs terminés et échoués.
Activez la stratégie de nettoyage en définissant le spec.successfulJobsHistoryLimit et spec.failedJobsHistoryLimit champs sur votre objet CronJob :
apiVersion: batch/v1 kind: CronJob metadata: name: demo-cron spec: schedule: "* * * * *" successfulJobsHistoryLimit: 5 failedJobsHistoryLimit: 10 jobTemplate: spec: template: spec: containers: - name: demo-cron image: busybox:latest command: ["/bin/sh", "-c", "Job complete!"]
Le CronJob illustré ci-dessus conservera les objets Job de ses 10 dernières exécutions ayant échoué, ainsi que les cinq dernières réussies.
Vous aurez un maximum de 15 anciens Jobs dans votre cluster à tout moment. Ces 15 seront conservés indéfiniment. Ils ne seront supprimés que lorsqu’ils seront remplacés par un travail plus récent qui se terminera avec le même statut.
Les limites d’historique CronJob par défaut sont appliquées lorsque vous omettez des valeurs personnalisées dans votre manifeste. Kubernetes conserve généralement trois tâches réussies et une qui a échoué. La valeur 0 est pris en charge pour supprimer les tâches immédiatement après leur fin, sans en conserver aucune.
TTL de travail fini
Les tâches TTL sont un ajout récent à Kubernetes qui est devenu stable dans la v1.23. Les durées de vie sont définies directement sur vos objets Job, vous n’avez donc pas besoin d’utiliser CronJobs. Le TTL ordonne à Kubernetes de supprimer la tâche et ses pods après qu’un temps fixe s’est écoulé, quel que soit l’état d’achèvement de la tâche.
Vous pouvez activer ce mécanisme en définissant le spec.ttlSecondsAfterFinished sur vos objets Job :
apiVersion: batch/v1 kind: Job metadata: name: demo-job spec: ttlSecondsAfterFinished: 300 template: spec: containers: - name: demo-cron image: busybox:latest command: ["/bin/sh", "-c", "Job complete!"]
Si votre Job est défini dans le cadre d’un CronJob, assurez-vous d’imbriquer le champ dans le jobTemplate:
apiVersion: batch/v1 kind: CronJob metadata: name: demo-cron spec: schedule: "* * * * *" jobTemplate: spec: ttlSecondsAfterFinished: 300 template: spec: containers: - name: demo-cron image: busybox:latest command: ["/bin/sh", "-c", "Job complete!"]
Les exemples ci-dessus marqueront les travaux comme éligibles à la suppression cinq minutes (300 secondes) après leur fin. Cela se produit indépendamment du fait que le Job se retrouve à l’état Complete ou Failed.
Les suppressions basées sur ce mécanisme sont gérées par un contrôleur dédié au sein de votre cluster. Le contrôleur surveille les objets Job, détecte l’expiration d’un TTL, puis prend des mesures pour nettoyer le Job affecté et ses ressources dépendantes. Il peut y avoir un court délai entre l’expiration du TTL et l’intervention du contrôleur pour activer la suppression.
Définition de la durée de vie d’un travail sur 0 le rendra éligible à la suppression dès qu’il sera terminé. Vous devez vous demander si cela convient à chacune de vos tâches. Ne pas conserver d’historique peut compliquer le débogage des problèmes, car vous ne pourrez pas récupérer les journaux de conteneur.
La ttlSecondsAfterFinished le champ est modifiable. Vous pouvez le modifier à tout moment sur les Jobs existants. Cependant, il n’est pas garanti que les modifications affectent les exécutions qui ont déjà été créées. L’extension de la durée de vie d’un travail peut toujours supprimer des exécutions planifiées alors que la valeur précédente s’appliquait.
Suppression manuelle de travaux
Vous pouvez toujours supprimer manuellement un Job à l’aide de Kubectl. Récupérez d’abord votre liste de Jobs :
$ kubectl get jobs NAME COMPLETIONS DURATION AGE demo-cron-27549499 1/1 2s 36s
Prochaine émission le delete job commande avec le nom de votre travail sélectionné :
$ kubectl delete job demo-cron-27549499 job.batch "demo-cron-27549499" deleted
Cela supprimera le travail et nettoiera les pods et autres objets qui lui sont associés.
Suppressions par lots à la demande
Vous pouvez nettoyer rapidement plusieurs Jobs en filtrant avec des sélecteurs de champs. Voici un exemple qui supprimera toutes les tâches réussies dans votre espace de noms actif :
$ kubectl delete jobs --field-selector status.successful=1 job.batch "demo-cron-27549501" deleted job.batch "demo-cron-27549502" deleted job.batch "demo-cron-27549503" deleted
C’est beaucoup moins laborieux que de supprimer des Jobs individuels en séquence.
Pour supprimer tous les Jobs associés à un CronJob spécifique, il est préférable de définir une étiquette sur ces Jobs qui identifie le CronJob parent. Définissez le libellé à l’aide de vos CronJob spec.jobTemplate.metadata.labels champ:
apiVersion: batch/v1 kind: CronJob metadata: name: demo-cron spec: schedule: "* * * * *" jobTemplate: metadata: labels: cron-job: demo-cron spec: template: spec: containers: - name: demo-cron image: busybox:latest command: ["/bin/sh", "-c", "Job complete!"]
Vous pouvez supprimer des Jobs créés par cette version du demo-cron CronJob à l’aide de la commande suivante :
$ kubectl delete jobs -l cron-job=demo-cron job.batch "demo-cron-27549501" deleted job.batch "demo-cron-27549502" deleted job.batch "demo-cron-27549503" deleted
La combinaison de cet exemple avec un sélecteur de champ vous permet de supprimer demo-cron exécutions qui sont dans un état particulier :
$ kubectl delete jobs -l cron-job=demo-cron --field-selector status.successful=0 job.batch "demo-cron-27549501" deleted job.batch "demo-cron-27549502" deleted job.batch "demo-cron-27549503" deleted
Cette commande supprime les Jobs en échec planifiés par le demo-cron Tâche planifiée.
Sommaire
Les tâches Kubernetes restent généralement dans votre cluster une fois terminées. Ce comportement vous permet de récupérer leurs journaux à des moments futurs arbitraires, mais conduit rapidement à une accumulation excessive d’objets.
Les CronJobs sont livrés avec des limites de rétention qui sont activées par défaut et prennent en charge une configuration distincte pour les exécutions réussies et échouées. Cela devrait être votre mécanisme préféré pour gérer les Jobs planifiés. D’autres types de Job sont mieux configurés avec un TTL qui nettoiera automatiquement les ressources après une période de temps fixe.
Bien que Kubernetes ait historiquement conservé les anciens Jobs indéfiniment, il est désormais recommandé d’utiliser le mécanisme TTL dans la mesure du possible. Avoir trop d’anciens Jobs dans votre cluster peut entraîner une dégradation des performances car le plan de contrôle doit surveiller les objets et les pods qu’ils ont créés.
