Jobs run Pods to completion; CronJobs create Jobs on a schedule. This lab controls retries, deadlines, concurrency, history, manual triggering, log retrieval, and cleanup.
1. Prepare and execute
Confirm the active kubeconfig context and namespace before applying changes. Save commands and manifests in version control without credentials.
kubectl create namespace jobs-lab
kubectl -n jobs-lab create job one-time --image=busybox:1.37 -- sh -c 'date -u; echo completed'
kubectl -n jobs-lab wait --for=condition=complete job/one-time --timeout=90s
kubectl -n jobs-lab logs job/one-time
2. Declarative configuration
Save the following example in a clearly named YAML file, review it, then use server-side dry-run when the API is available.
apiVersion: batch/v1
kind: CronJob
metadata: {name: heartbeat, namespace: jobs-lab}
spec:
schedule: '*/5 * * * *'
concurrencyPolicy: Forbid
startingDeadlineSeconds: 120
successfulJobsHistoryLimit: 2
failedJobsHistoryLimit: 2
jobTemplate:
spec:
backoffLimit: 2
activeDeadlineSeconds: 60
template:
spec:
restartPolicy: Never
containers:
- name: task
image: busybox:1.37
command: [sh, -c, 'date -u; echo heartbeat']
3. Verify the result
A successful command is not enough. Inspect resource state, conditions, events, endpoints, logs, and an end-to-end request where applicable.
kubectl apply -f cronjob.yaml
kubectl -n jobs-lab get cronjob
kubectl -n jobs-lab create job --from=cronjob/heartbeat heartbeat-manual
kubectl -n jobs-lab logs -f job/heartbeat-manual
kubectl -n jobs-lab get jobs,pods
4. Troubleshooting
Check CronJob last schedule time, suspended state, controller events, Job conditions, and Pod logs. Cron schedules use the controller’s interpretation and optional timeZone field; verify business-time expectations.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl -n jobs-lab delete cronjob heartbeat
kubectl delete namespace jobs-lab
Production checklist
- The active context, namespace, and target version were verified.
- Manifests passed client or server-side validation.
- Resource conditions and recent events show no unresolved error.
- Access, network exposure, resource limits, persistence, and rollback were reviewed.
- Commands and expected output were recorded for the operating team.
References: topic documentation and Kubernetes documentation.
