Cron Latest
Scale applications based on a cron schedule.
Trigger Specification
This specification describes the cron
trigger that scales workloads in/out based on a cron Schedule.
triggers:
- type: cron
metadata:
# Required
timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database.
start: 0 6 * * * # At 6:00 AM
end: 0 20 * * * # At 8:00 PM
desiredReplicas: "10"
Parameter list:
timezone
- One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found here.start
- Cron expression indicating the start of the cron schedule.end
- Cron expression indicating the end of the cron schedule.desiredReplicas
- Number of replicas to which the resource has to be scaled between the start and end of the cron schedule.
💡 Note:
start
/end
support “Linux format cron” (Minute Hour Dom Month Dow).
Notice: Start and end should not be the same.
For example, the following schedule is not valid:
start: 0 6 * * * # At 6:00 AM end: 0 6 * * * # also at 6:00 AM
How does it work?
The CRON scaler allows you to define a time range in which you want to scale your workloads out/in.
When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.
What the CRON scaler does not do, is scale your workloads based on a recurring schedule.
Scale to 0 during off hours
If you want to scale your deployment to 0 outside office hours / working hours,
you need to set minReplicaCount: 0
in the ScaledObject, and increase the
replicas during work hours. That way the Deployment will be scaled to 0 outside
that time window. By default the ScaledObject cooldownPeriod
is 5 minutes, so the actual
scaling down will happen 5 minutes after the cron schedule end
parameter.
It’s almost always an error to try to do it the other way
around, i.e. set desiredReplicas: 0
in the cron trigger.
💡 NOTE: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (
max(metrics)
), the value set fordesiredReplicas
technically acts as a “dynamic” minimum replicas. For example, if you have other trigger like CPU, during the time betweenstart
andend
you will have AT LEASTdesiredReplicas
because of thatmax(metrics)
.
Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are ignored, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, pod-related metrics are also ignored for scaling to zero and this process is done only considering external metrics.
TL;DR
- Set
minReplicaCount
to 0 - Create your
cron
trigger: definestart
,end
andtimezone
, and setdesiredReplicas
to the previous value ofminReplicaCount
- If you also want to use other criteria to scale your deployment, just add other triggers to your
ScaledObject
Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: cron-scaledobject
namespace: default
spec:
scaleTargetRef:
name: my-deployment
minReplicaCount: 0
cooldownPeriod: 300
triggers:
- type: cron
metadata:
timezone: Asia/Kolkata
start: 0 6 * * *
end: 0 20 * * *
desiredReplicas: "10"
Example: dynamic number of replicas (0 during night, between 1 and 4 during day)
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: cron-scaledobject
namespace: default
spec:
scaleTargetRef:
name: my-deployment
minReplicaCount: 0
maxReplicaCount: 4
cooldownPeriod: 300
triggers:
- type: cron
metadata:
timezone: Asia/Kolkata
start: 0 6 * * *
end: 0 20 * * *
desiredReplicas: "1"
- type: cpu
metricType: Utilization
metadata:
value: "80"
The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.