Gründe und Gegenmaßnahmen dafür, dass KEDA ScaledJob-Pods nicht automatisch gelöscht werden

In KEDAs ScaledJob werden die abgeschlossenen Jobs gelöscht, wenn die Anzahl die in "successJobsHistoryLimit" angegebene Anzahl überschreitet. Aus irgendeinem Grund werden die von Job erstellten Pods jedoch nicht gelöscht.

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
}

Nachdem ich nach verschiedenen Dingen gesucht hatte, stieß ich auf den nächsten Artikel. Sorgfältig bis zum Namen des Einstellungselements. Nun, von den Ressourcen, auf die ich mich bezog, als ich über dieses Einstellungselement nachdachte, ist es der gleiche Name.

• Orphaned pods after job is deleted via successfulJobsHistoryLimit

Was hier geschrieben wurde ist, dass es hauptsächlich zwei "ownerReference" -Metadaten gibt? Diese PR behebt das Problem. Diese PR ist der 6. Dezember 2018 Nr Es wurde zum Meilenstein von Version 1.13 hinzugefügt, sodass es anscheinend dort behoben wurde. Sie müssen sicherstellen, dass die Version von Kubernetes höher ist.

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

Was sind Eigentümerreferenzen?

• Garbage Collection

Wie in angegeben, wird dies wirksam, wenn Sie dies in Ihrer übergeordneten Ressourcenreferenz haben, wenn Sie die kaskadierende Löschrichtlinie festlegen. Andere Bedingungen wurden auf der Originalseite aufgeführt, daher kann es erforderlich sein, diese festzulegen.

Aktuelles Verhalten

Lassen Sie uns zuerst die aktuelle Situation überprüfen. Es gibt einen Job.

$ 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

Es gibt einen von Job erstellten Pod mit einer ähnlichen Benennung.

$ 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

Schauen wir uns den Inhalt mit kubectl edit pod an.

Ich wollte es nicht wissen, aber ownerReferences wird automatisch gesetzt. Jetzt legen wir die Richtlinie fest

PropagationPolicy

Betrachten von Job v1 Batch: Löschen , PropagationPolicy scheint gesetzt zu sein. Es stehen drei Werte zur Auswahl. Was mit der Standardeinstellung passiert, scheint von der Finalizer-Einstellung der Ressource abzuhängen, aber ich bin eine benutzerdefinierte Ressource und sie ist nicht definiert. Wählen Sie zwischen "Hintergrund" oder "Vordergrund".

• '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.

Beschreibung in der Client-Anwendung

Es war einfach, weil ich nur die Richtlinie festlegen musste, um das Problem zu beheben. Als ich es tatsächlich ausprobierte, funktionierten sowohl "DeletePropagationBackground" als auch "DeletePropagationForeground" korrekt, aber der Hintergrund wurde auch schnell genug gelöscht. Machen Sie also die Standardeinstellung zum Standard, anstatt darauf zu warten, dass der Pod gelöscht wird. Ich habe es gemacht.

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

Alte benutzerdefinierte Ressourcen können nicht gelöscht werden

Jetzt hatte der alte Keda ScaledJob ein Problem, bei dem alte benutzerdefinierte Ressourcen nicht gelöscht werden konnten. Es scheint, dass "Finalizer" gesetzt wurde und das Entfernen verhindert hat. Ich fragte mich, warum es nicht verschwinden würde, egal wie oft ich es löschte, aber ich löste es, indem ich dem Problem hier folgte. Sie können es jetzt entfernen, indem Sie die Definition des Finalizers entfernen.

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

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

abschließend

Die k8s-Oberfläche ist unkompliziert, leicht zu verstehen und macht Spaß!