如何实现Kubernetes CronJob在每个节点周期性执行备份脚本？

Great question! This is a super common pain point when you need cluster-wide periodic tasks that run on every node without manual node management. Since Kubernetes doesn’t natively support a "CronDaemonSet" (as you noted in that unresolved issue), here are three actionable approaches to get this done:

1. CronJob + One-Time DaemonSet (Dynamic Node Coverage) #

This approach uses a CronJob to trigger a helper Pod that creates a temporary DaemonSet for each backup run. Once all nodes finish their backup tasks, the helper cleans up the DaemonSet.

How to implement: #

• Step 1: Set up permissions
  Create a ServiceAccount with permissions to create/delete DaemonSets and monitor Pod status. Bind it to a ClusterRole that allows actions like daemonsets/create, daemonsets/delete, and pods/watch.
• Step 2: Write the CronJob
  Define a CronJob whose jobTemplate runs a Pod with your helper script. The Pod will use the service account you created to interact with the Kubernetes API.
• Step 3: Helper script logic
  Your script should:
  • Generate a unique temporary DaemonSet (e.g., append a timestamp to the name) with your backup Pod template—include volume mounts, your backup script, and set restartPolicy: OnFailure.
  • Wait until all Pods in the DaemonSet have completed (either succeeded or failed).
  • Delete the temporary DaemonSet to clean up resources.

Pros: #

• Fully dynamic: Automatically includes new nodes added to the cluster between backup runs.
• Clean resource usage: No long-running Pods—everything is cleaned up after each backup.
• Strict periodic execution: Aligns exactly with your Cron schedule.

Cons: #

• Requires writing and maintaining the helper script (handling API interactions, waiting for Pod completion).
• Adds permission overhead for the service account.

2. DaemonSet + Internal Scheduling (Simplest Approach) #

Instead of using CronJob, run a long-running DaemonSet on every node, and handle the periodic backup schedule inside each Pod.

How to implement: #

• Step 1: Build a custom image
  Create a Docker image that includes your backup script plus a scheduling tool like supercronic (a lightweight, Kubernetes-friendly cron alternative) or even a simple shell loop.
• Step 2: Define the DaemonSet
  Configure the DaemonSet to mount your required volumes, set restartPolicy: OnFailure, and run your scheduling tool/script. For example, with supercronic, you’d include a cron file like */60 * * * * /path/to/backup-script.sh.

Pros: #

• Dead simple to set up and maintain—no API interactions or extra permissions needed.
• Each node’s backup task runs independently; if a backup fails, the Pod restarts (thanks to OnFailure policy) to retry.
• Works seamlessly with dynamic node additions (DaemonSet automatically schedules on new nodes).

Cons: #

• Pods run continuously, consuming minimal but persistent resources.
• Changing the backup schedule requires updating the DaemonSet (or the cron config if you mount it as a ConfigMap).
• If a Pod crashes between backup runs, you’ll miss the next scheduled backup until the Pod restarts.

3. Custom Operator (For Advanced Use Cases) #

If you need more control or plan to extend this functionality long-term, build a simple custom operator that watches a custom resource (e.g., CronDaemonSet) and manages periodic DaemonSet creation/cleanup automatically.

How to implement: #

• Use tools like Operator SDK or Kubebuilder to scaffold an operator.
• Define a custom CRD that combines Cron schedule parameters with DaemonSet specs.
• The operator will trigger DaemonSet creation on the specified schedule, monitor completion, and clean up resources.

Pros: #

• Fully customizable to your exact needs.
• Clean, declarative configuration (define your CronDaemonSet once, let the operator handle the rest).
• Easy to extend with features like backup status reporting, retries, or alerts.

Cons: #

• Higher upfront development and maintenance effort.
• Adds an extra component to your cluster that needs monitoring and updates.

Which Approach Should You Choose? #

• Go with Option 2 if you want simplicity and don’t mind long-running Pods.
• Choose Option 1 if you need strict periodic execution without persistent Pods.
• Use Option 3 only if you have advanced requirements that the first two approaches can’t meet.

内容的提问来源于stack exchange，提问作者Daniel Szot