Raisons et contre-mesures pour lesquelles les pods KEDA ScaledJob ne sont pas automatiquement supprimés

Lorsque le nombre de Jobs terminés dépasse le nombre spécifié par successJobsHistoryLimit dans ScaledJob de KEDA, les Jobs terminés seront supprimés, mais pour une raison quelconque, les pods créés par Job ne sont pas supprimés.

func (e *scaleExecutor) deleteJobsWithHistoryLimit(logger logr.Logger, jobs []batchv1.Job, historyLimit int32) error {
	if len(jobs) <= int(historyLimit) {
		return nil
	}

	deleteJobLength := len(jobs) - int(historyLimit)
	for _, j := range (jobs)[0:deleteJobLength] {
		err := e.client.Delete(context.TODO(), j.DeepCopyObject())
		if err != nil {
			return err
		}
		logger.Info("Remove a job by reaching the historyLimit", "job.Name", j.ObjectMeta.Name, "historyLimit", historyLimit)
	}
	return nil
}

Après avoir recherché diverses choses, je suis tombé sur l'article suivant. Soigneusement le même jusqu'au nom de l'élément de réglage. Eh bien, d'après les ressources auxquelles j'ai fait référence lorsque j'ai pensé à cet élément de réglage, c'est le même nom.

• Orphaned pods after job is deleted via successfulJobsHistoryLimit

Ce qui a été écrit ici, ce sont principalement deux métadonnées ʻownerReference`? Ce PR résout le problème. Ce PR est le 6 décembre 2018 non Il a été ajouté à l'étape de la v1.13, il semble donc qu'il y ait été corrigé. Vous devez vous assurer que la version de kubernetes est supérieure.

  ownerReferences:
  - apiVersion: batch/v1
    blockOwnerDeletion: true
    controller: true
    kind: Job
    name: <job-name>
    uid: 94ff084e-1a5b-11e9-b123-52540098c2e3

Que sont les références de propriétaire?

• Garbage Collection

Comme indiqué dans, si vous l'avez dans votre référence de ressource parent, cela prendra effet lorsque vous définissez la stratégie de suppression en cascade. D'autres conditions étaient répertoriées sur la page d'origine, il peut donc être nécessaire de les définir.

Comportement actuel

Vérifions d'abord la situation actuelle. Il y a un emploi.

$ kubectl get jobs
NAME                                    COMPLETIONS   DURATION   AGE
azure-servicebus-queue-consumer-7x629   1/1           8s         114s
azure-servicebus-queue-consumer-9m7v6   0/1           3s         3s
azure-servicebus-queue-consumer-lqftl   1/1           6s         66s
azure-servicebus-queue-consumer-qjfhr   1/1           10s        2m25s
azure-servicebus-queue-consumer-qs5rb   1/1           20s        49s
azure-servicebus-queue-consumer-v8n7m   1/1           8s         60s

Il existe un pod créé par Job et il a un nom similaire.

$ kubectl get pods
NAME                                          READY   STATUS      RESTARTS   AGE
azure-servicebus-queue-consumer-7x629-8kc2j   0/1     Completed   0          2m28s
azure-servicebus-queue-consumer-9m7v6-zgzsf   0/1     Completed   0          37s
azure-servicebus-queue-consumer-lqftl-67pnv   0/1     Completed   0          99s
azure-servicebus-queue-consumer-qjfhr-dhbgt   0/1     Completed   0          2m59s
azure-servicebus-queue-consumer-qs5rb-8qsr7   0/1     Error       0          83s
azure-servicebus-queue-consumer-qs5rb-v2d7d   0/1     Completed   0          70s
azure-servicebus-queue-consumer-v8n7m-dczp8   0/1     Completed   0          94s

Jetons un coup d'œil au contenu en utilisant kubectl edit pod.

Je ne voulais pas en être conscient, mais ʻownerReferences` est automatiquement défini. Maintenant, définissons la politique

PropagationPolicy

En regardant Job v1 batch: Delete , PropagationPolicy semble être défini. Vous avez le choix entre trois valeurs. Ce qu'il advient de la valeur par défaut semble dépendre des paramètres du finaliseur de la ressource, mais je suis une ressource personnalisée et elle n'est pas définie. Choisissez entre «arrière-plan» ou «premier plan».

• 'Orphan' - orphan the dependents;
• 'Background' - allow the garbage collector to delete the dependents in the background;
• 'Foreground' - a cascading policy that deletes all dependents in the foreground.

Description dans l'application client

C'était facile car tout ce que j'avais à faire était de définir la politique pour y remédier. Quand je l'ai essayé, les deux DeletePropagationBackground et DeletePropagationForeground fonctionnaient correctement, mais l'arrière-plan a également été supprimé assez rapidement, alors faites du paramètre Arrière-plan la valeur par défaut au lieu d'attendre que le pod soit supprimé. Je l'ai fait.

deletePolicy := metav1.DeletePropagationBackground
deleteOptions := &client.DeleteOptions{
    PropagationPolicy: &deletePolicy,
}
err := e.client.Delete(context.TODO(), j.DeepCopyObject(), deleteOptions)
if err != nil {
    return err
}

L'ancienne ressource personnalisée ne peut pas être supprimée

Maintenant, l'ancien Keda ScaledJob avait un problème où les anciennes ressources personnalisées ne pouvaient pas être supprimées. Il semble que "finaliseur" ait été défini et qu'il a empêché la suppression. Je me suis demandé pourquoi il ne disparaîtrait pas, quel que soit le nombre de fois où je l'ai supprimé, mais je l'ai résolu en suivant le problème ici. Vous pouvez maintenant le supprimer en supprimant la définition de finaliseur.

kubectl patch scaledjob -p '{"metadata":{"finalizers":[]}}' --type=merge

• Custom resources with finalizers can "deadlock" customresourcecleanup.apiextensions.k8s.io finalizer

en conclusion

L'interface k8s est simple, facile à comprendre et amusante!