instruction: Create a Dockerfile for workloads
output: ```dockerfile
  from the failed and the replacement Job running at the same time, using
  extra compute resources.Alternatively, if your cluster has limited resource capacity, you could choose to
  wait until the Failed condition appears on the Job, which would delay your
  replacement Job but would ensure that you conserve resources by waiting
  until all of the failed Pods are removed.Clean up finished jobs automaticallyFinished Jobs are usually no longer needed in the system. Keeping them around in
  the system will put pressure on the API server. If the Jobs are managed directly
  by a higher level controller, such as
  CronJobs, the Jobs can be
  cleaned up by CronJobs based on the specified capacity-based cleanup policy.TTL mechanism for finished JobsFEATURE STATE:
  Kubernetes v1.23 [stable]Another way to clean up finished Jobs (either Complete or Failed)
  automatically is to use a TTL mechanism provided by a
  TTL controller for
  finished resources, by specifying the .spec.ttlSecondsAfterFinished field of
  the Job.When the TTL controller cleans up the Job, it will delete the Job cascadingly,
  i.e. delete its dependent objects, such as Pods, together with the Job. Note
  that when the Job is deleted, its lifecycle guarantees, such as finalizers, will
  be honored.For example:apiVersion: batch/v1
  kind: Job
  metadata:
   name: pi-with-ttl
  spec:
   ttlSecondsAfterFinished: 100
   template:
   spec:
   containers:
   - name: pi
   image: perl:5.34.0
   command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
   restartPolicy: Never
  The Job pi-with-ttl will be eligible to be automatically deleted, 100
  seconds after it finishes.If the field is set to 0, the Job will be eligible to be automatically deleted
  immediately after it finishes. If the field is unset, this Job won't be cleaned
  up by the TTL controller after it finishes.Note:It is recommended to set ttlSecondsAfterFinished field because unmanaged jobs
  (Jobs that you created directly, and not indirectly through other workload APIs
  such as CronJob) have a default deletion
  policy of orphanDependents causing Pods created by an unmanaged Job to be left around
  after that Job is fully deleted.
  Even though the control plane eventually
  garbage collects
  the Pods
  ```