/sig apps

Do you mean something like RandomizedDelaySec?

Here is a workaround: run command like sleep $(shuf -i 10-20 -n 1) before your job cmd

[root@dce-10-7-177-7 ~]# docker logs 2a17fadddca1
Wed Jun  3 03:25:01 UTC 2020
Wed Jun  3 03:25:09 UTC 2020
Hello from the Kubernetes cluster
[root@dce-10-7-177-7 ~]# kubectl get pod
NAME                     READY   STATUS      RESTARTS   AGE
dao-2048                 1/1     Running     2          17h
hello-1591154640-qk4ng   0/1     Completed   0          83s
hello-1591154700-5ftww   0/1     Completed   0          23s
myapp-pod                0/1     Init:0/2    0          73m
[root@dce-10-7-177-7 ~]# kubectl get job
NAME               COMPLETIONS   DURATION   AGE
hello-1591154640   1/1           69s        86s
hello-1591154700   1/1           18s        26s
[root@dce-10-7-177-7 ~]# kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        32s             2m
[root@dce-10-7-177-7 ~]# kubectl get cronjob -o yaml
apiVersion: v1
items:
- apiVersion: batch/v1beta1
  kind: CronJob
  metadata:
    creationTimestamp: "2020-06-03T03:23:32Z"
    name: hello
    namespace: default
    resourceVersion: "1005216"
    selfLink: /apis/batch/v1beta1/namespaces/default/cronjobs/hello
    uid: a3ab0566-11ba-47d7-8e70-8918a55926f0
  spec:
    concurrencyPolicy: Allow
    failedJobsHistoryLimit: 1
    jobTemplate:
      metadata:
        creationTimestamp: null
      spec:
        template:
          metadata:
            creationTimestamp: null
          spec:
            containers:
            - args:
              - /bin/sh
              - -c
              - date;sleep $(shuf -i 5-10 -n 1);date;echo Hello from the Kubernetes
                cluster
              image: busybox
              imagePullPolicy: Always
              name: hello
              resources: {}
              terminationMessagePath: /dev/termination-log
              terminationMessagePolicy: File
            dnsPolicy: ClusterFirst
            restartPolicy: OnFailure
            schedulerName: default-scheduler
            securityContext: {}
            terminationGracePeriodSeconds: 30
    schedule: '*/1 * * * *'
    successfulJobsHistoryLimit: 3
    suspend: false
  status:
    lastScheduleTime: "2020-06-03T03:25:00Z"
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

/assign @soltysh

/cc @MikeSpreitzer

I briefly thought about the new API Priority and Fairness feature in the apiservers, but that will not directly do the trick because your concern is not with apiserver requests but rather running workload in pods.

A generalization of leader-election to directly enforce a concurrency limit would probably do the trick, but may be heavier weight than is needed here. I like the random delay idea.

I would like to have the Jenkins-Syntax supported!
In Jenkins you can put an "H" instead of a number, e.g. in the minutes-field, to indicate that the task is performed every hour at an unspecified but invariant time for each task.

Randomizing execution would be awesome. +1 for 'H' support (Hashed) https://en.wikipedia.org/wiki/Cron#Non-standard_characters

The Jenkins syntax can be found at https://www.jenkins.io/doc/book/pipeline/syntax/#cron-syntax

once in every two hours slot between 9 AM and 5 PM every weekday (perhaps at 10:38 AM, 12:38 PM, 2:38 PM, 4:38 PM)

H H(9-16)/2 * * 1-5

But maybe a more modern route is to go with options like for the systemd.timer using systemd.time format .

This sample from snapd.snap-repair.timer:

OnCalendar=*-*-* 5,11,17,23:00
RandomizedDelaySec=2h
AccuracySec=10min
OnStartupSec=15m

It does not have the concurrency limit mentioned earlier, but the AccuracySec can allow adjusting pod starts for example on load. With the status info on the Jobs previously run there would be potential for some smart scheduling if anyone finds that useful.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

/remove-lifecycle stale
/lifycycle frozen

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

Is this planned?

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

/reopen

@szuecs: Reopened this issue.

/remove-lifecycle rotten

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

Is this being worked on?

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

We have a use-case where we run a periodic synchronization cronjob across projects, and as all these cronjobs start their pod at the same time, it increases database load significantly (as the underlying database is the same for all these projects). This load increase would be reduced if the cronjobs would not all start at the same time.

For such short-lived cronjobs, the suggested "workaround" of using an initContainer with a random sleep command would not do for Kubernetes offers where you pay with your pod usage and not the nodes (e.g. with GKE Autopilot): adding these sleep commands would increase the cost as the pods may live a bit longer (though it depends to the database load too in my case...).

Another way to resolve this would be to implement the RANDOM_DELAY variable like cronie does.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale