Define the schedule of a plan

[dcardellino]

Hello together,

Sorry for the maybe dumb question, but how can I define how often a plan is scheduled on the cluster?
I created a plan according to the examples for ubuntu bionic, but the plan only did run once.

Is there any option to run it in a specific schedule?

[dweomer]

A plan is an outstanding intent to mutate any node (subject to node-selector criteria) such that after the plan is run on a node successfully the controller will label it with plan.upgrade.cattle.io/${plan.name}=${plan.status.latestHash}. For simple plans, the ${plan.status.latestHash} value is a sha256sum of ${plan.spec.serviceAccountName} and ${plan.status.latestVersion}. See https://github.com/rancher/system-upgrade-controller/blob/master/pkg/upgrade/plan/plan.go#L61-L84 for more detail.

So, to force a plan to run on a scheduled you would need to periodically change something on the plan spec that results in a new ${plan.status.latestHash}:

• override ${plan.spec.version} ➡️ ${plan.status.latestVersion}
• modify an associated secret (secret data is digested so you could store a simple increasing value)

[sebastiangaiser]

I was thinking about a Kubernetes CronJob which is performing these changes. At least this could also be a starting point for a new crd (e.g. CronPlan) which creates a Plan resource and and CronJob resource.

I personally would really like to have an automation around this topic.

[dweomer]

I was thinking about a Kubernetes CronJob which is performing these changes. At least this could also be a starting point for a new crd (e.g. CronPlan) which creates a Plan resource and and CronJob resource.

Interesting thought. One of the things I've enjoyed most about SUC is it's re-use of k8s types to, if you'll excuse the pun, get the job done. And so, a commensurate appropriation of CronJob is appealing. I wonder if it might be a bit too much square peg round hole though? I haven't worked with the CronJob type much but I tend to think of it as more appropriate for recurring executions (but maybe that's my bias).

I personally would really like to have an automation around this topic.

I agree, it can feel like building a Rube Goldberg machine to get k8s to do what one requires of it (component A to feed component B to feed component C ...)

[iMikeG6]

Hi there,

here is a basic implementation of a k8s cronjob that schedule a plan everyday at 04am.
Based on @dweomer said about overriding ${plan.spec.version}, the script in the configmap should do the trick

version: "$(date +'%Y-%m-%d-%H%M')"

Basically, what it does is running a alpine/k8s:1.25.9 which then execute a script that apply a plan in the system-upgrade namespace. As kubectl apply a yaml file which has a different date every time, the hash should change and so the os upgrade should be executed.

First, create your secret:

upgrade-os-secret.yml:

---
apiVersion: v1
kind: Secret
metadata:
  name: upgrade-os
  namespace: system-upgrade
type: Opaque
stringData:
  upgrade.sh: |
    #!/bin/sh
    set -e
    # This should be working with all the RedHat family version >=8
    yum update -y
    if dnf needs-restarting -r | grep "Reboot is required"; then
      reboot
    fi

Create configmap for your cronjob

upgrade-schedule-configmap.yml:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: upgrade-schedule-configmap
  namespace: system-upgrade
data:
  template: |
    #!/bin/sh
    cat <<EOF | kubectl apply -f -
    apiVersion: upgrade.cattle.io/v1
    kind: Plan
    metadata:
      name: upgrade-os
      namespace: system-upgrade
    spec:
      concurrency: 1
      nodeSelector:
        matchExpressions:
          - {key: beta.kubernetes.io/os, operator: In, values: ["linux"]}
      tolerations:
        - operator: Exists
      serviceAccountName: system-upgrade
      secrets:
        - name: upgrade-os
          path: /host/run/system-upgrade/secrets/upgrade-os
      drain:
        deleteLocalData: true
        ignoreDaemonSets: true
        force: true
        disableEviction: true
        skipWaitForDeleteTimeout: 60
      version: "$(date +'%Y-%m-%d-%H%M')"
      upgrade:
        image: alpine:3.2
        command: ["chroot", "/host"]
        args: ["sh", "/run/system-upgrade/secrets/upgrade-os/upgrade.sh"]
    EOF

And finally create the cronjob

upgrade-schedule-cronjob.yml

---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: upgrade-schedule-cronjob
  namespace: system-upgrade
spec:
  schedule: "0 4 * * *"
  successfulJobsHistoryLimit: 0
  failedJobsHistoryLimit: 0
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        metadata:
          name: upgrade-schedule-cronjob
        spec:
          containers:
            - image: alpine/k8s:1.25.9
              args:
                - "/apps/apply_plan.sh"
              imagePullPolicy: IfNotPresent
              name: upgrade-schedule-cronjob
              volumeMounts:
                - name: upgrade-schedule-configmap
                  readOnly: true
                  mountPath: /apps/apply_plan.sh
                  subPath: apply_plan.sh
          serviceAccountName: system-upgrade
          restartPolicy: "Never"
          volumes:
            - name: upgrade-schedule-configmap
              configMap:
                name: upgrade-schedule-configmap
                items:
                  - key: template
                    path: apply_plan.sh
                    mode: 493

Feel free to use and edit according to your needs.

Hope this helps