Annotations reference
All Workload Autoscaler settings are available by adding annotations to the workload controller. When the workloads.cast.ai/configuration annotation is detected on a workload, it will be considered as configured by annotations. This allows for flexible configuration, combining annotations and scaling policies.
Changes to the settings via the API/UI are no longer permitted for workloads with annotations. The default or scaling policy value is used when a workload does not have an annotation for a specific setting.
Annotation values take precedence over what is defined in a scaling policy. This means that if a scaling policy is defined in the workload configuration under annotations, all of the individual configuration options defined under the annotation will override the respective policy values. Those that are not defined under the annotation will use system defaults or what is defined in the scaling policy.
Example
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
labels:
app: my-app
annotations:
workloads.cast.ai/configuration: |
scalingPolicyName: custom
vertical:
optimization: on
applyType: immediate
antiAffinity:
considerAntiAffinity: false
startup:
period: 5m
confidence:
threshold: 0.5
cpu:
target: p81
lookBackPeriod: 25h
min: 1000m
max: 2500m
applyThresholdStrategy:
type: defaultAdaptive
overhead: 0.15
limit:
type: multiplier
multiplier: 2.0
memory:
target: max
lookBackPeriod: 30h
min: 2Gi
max: 10Gi
applyThresholdStrategy:
type: defaultAdaptive
overhead: 0.35
limit:
type: noLimit
downscaling:
applyType: immediate
memoryEvent:
applyType: immediate
containers:
{container_name}:
cpu:
min: 10m
max: 1000m
memory:
min: 10Mi
max: 2048Mi
rolloutBehavior:
type: NoDisruption
preferOneByOne: true
horizontal:
optimization: on
minReplicas: 5
maxReplicas: 10
scaleDown:
stabilizationWindow: 5m
containersGrouping:
- key: name
operator: contains
values: ["data-processor"]
into: data-processorConfiguration Structure
Below is a configuration structure reference for setting up a workload to be controlled by annotations.
Note
workloads.cast.ai/configurationhas to be a valid YAML string. In cases where the annotation contains an invalid YAML string, the entire configuration will be ignored.
scalingPolicyName
If not set, the system will use the default scaling policy.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
scalingPolicyName | string | No | "default" | Specifies the scaling policy name to use. When set, this annotation allows the workload to be managed by both annotations and the specified scaling policy. The scaling policy can control global settings like enabling/disabling vertical autoscaling. |
scalingPolicyName: custom-policyvertical
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
vertical | object | No | - | Vertical scaling configuration. |
vertical:
optimization: on
applyType: immediate
antiAffinity:
considerAntiAffinity: false
startup:
period: 5m
confidence:
threshold: 0.5vertical.optimization
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string |
| Enable vertical scaling ("on"/"off"). If using the |
vertical:
optimization: onvertical.applyType
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string | No | "immediate" | Allows configuring the autoscaler operating mode to apply the recommendations.
Use
|
vertical:
applyType: immediatevertical.antiAffinity
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
antiAffinity | object | No | - | Configuration for handling pod anti-affinity scheduling constraints. |
vertical:
antiAffinity:
considerAntiAffinity: falsevertical.antiAffinity.considerAntiAffinity
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| boolean |
|
| When
|
vertical:
antiAffinity:
considerAntiAffinity: falsevertical.startup
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| object | No | Configuration for handling workload startup behavior. See Startup metrics. |
vertical:
startup:
period: 5mvertical.startup.period
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| duration |
| "2m" | Duration to ignore resource usage metrics after workload startup. Useful for applications with high initial resource usage spikes. Set to Valid values range from
|
vertical:
startup:
period: 5m # Example: ignore first 5 minutes of metricsvertical:
startup:
period: 0s # Disable startup metrics ignore periodvertical.confidence
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
confidence | object | No | - | Configuration for recommendation confidence thresholds. |
vertical:
confidence:
threshold: 0.5
required: falsevertical.confidence.required
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| bool |
| When set to:
|
vertical:
confidence:
required: truevertical.confidence.threshold
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float |
| 0.9 | Minimum confidence score required to apply recommendations (0.0-1.0). Higher values require more data points for recommendations.
|
vertical:
confidence:
threshold: 0.5vertical.cpu
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
cpu | object | No | - | CPU-specific scaling configuration. |
vertical:
cpu:
target: p80
lookBackPeriod: 24h
min: 100m
max: 1000m
applyThresholdStrategy:
type: defaultAdaptive
overhead: 0.1vertical.cpu.target
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string | No | "p80" | Resource usage target:
|
vertical:
cpu:
target: p80vertical.cpu.lookBackPeriod
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| duration | No | "24h" | Historical resource usage data window to consider for recommendations (3h-168h). See Look-back Period. |
vertical:
cpu:
lookBackPeriod: 24hvertical.cpu.min
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
min | string | No | "10m" | The lower limit for the recommendation uses standard Kubernetes CPU notation (e.g., "1000m" or "1"). The minimum cannot be greater than the maximum. |
vertical:
cpu:
min: 100mvertical.cpu.max
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
max | string | No | - | The upper limit for the recommendation. It uses standard Kubernetes CPU notation (e.g., "1000m" or "1"). Recommendations will not exceed this value. |
vertical:
cpu:
max: 1000mvertical.cpu.applyThreshold
Deprecation NoticeThe
applyThresholdconfiguration option is deprecated but still supported for backward compatibility. We strongly recommend migrating to the newapplyThresholdStrategyconfiguration format for future compatibility and access to the latest features. See applyThresholdStrategy.
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float | No | 0.1 | The relative difference required between current and recommended resource values to apply a change immediately:
|
vertical:
cpu:
applyThreshold: 0.1vertical.cpu.applyThresholdStrategy
Warning
applyThresholdandapplyThresholdStrategycannot be used simultaneously in a configuration as that will result in an error.applyThresholdStrategyis the latest and recommended configuration option.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
applyThresholdStrategy | object | No | - | Configuration for the strategy used to determine when recommendations should be applied. The strategy determines how the threshold percentage is calculated based on current resource requests. |
vertical:
cpu:
applyThresholdStrategy:
type: defaultAdaptivevertical.cpu.applyThresholdStrategy.type
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string |
| "defaultAdaptive" | The type of threshold strategy to use:
|
vertical:
cpu:
applyThresholdStrategy:
type: defaultAdaptive # Using default adaptive thresholdvertical.cpu.applyThresholdStrategy.percentage
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float |
| The fixed percentage threshold to use. Value range: 0.01-2.5.
|
vertical:
cpu:
applyThresholdStrategy:
type: percentage # Using fixed percentage threshold
percentage: 0.3 # 30% thresholdvertical.cpu.applyThresholdStrategy.numerator
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float |
| 0.5 | Affects the vertical stretch of the threshold function. Lower values create smaller thresholds.
|
vertical:
cpu:
applyThresholdStrategy:
type: customAdaptive # Using custom adaptive threshold
numerator: 0.1
exponent: 0.1
denominator: 2vertical.cpu.applyThresholdStrategy.denominator
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float |
| 1 | Affects threshold sensitivity for small workloads. Values close to
|
vertical:
cpu:
applyThresholdStrategy:
type: customAdaptive
numerator: 0.1
exponent: 0.1
denominator: 2vertical.cpu.applyThresholdStrategy.exponent
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float |
| 1 | Controls how quickly the threshold decreases for larger workloads. Lower values prevent extremely small thresholds for large resources.
|
vertical:
cpu:
applyThresholdStrategy:
type: customAdaptive
numerator: 0.1
exponent: 0.1
denominator: 2vertical.cpu.overhead
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float | No | 0.1 | Additional resource buffer when applying recommendations (0.0-2.5, e.g., 0.1 = 10%). If a 10% buffer is configured, the issued recommendation will have +10% added to it, so that the workload can handle further increased resource demand. |
vertical:
cpu:
overhead: 0.1vertical.cpu.limit
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| object | No | Configuration for container CPU limit scaling. Default behaviour when not specified:
|
vertical:
cpu:
limit:
type: multiplier
multiplier: 2.0vertical.cpu.limit.type
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string | *Yes | Type of CPU limit scaling to apply:
*If using the |
vertical:
cpu:
limit:
type: keepLimitsvertical.cpu.limit.multiplier
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float | *Yes | Value to multiply the requests by to set the limit. The calculation is: *Required when type is set to |
vertical:
cpu:
limit:
type: multiplier
multiplier: 2.0vertical.cpu.limit.onlyIfOriginalExist
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| boolean | No | false | When set to This flag allows conditional limit management based on the original workload configuration. Only applicable when the type is set to |
vertical:
cpu:
limit:
type: multiplier
multiplier: 2.0
onlyIfOriginalExist: truevertical.cpu.limit.onlyIfOriginalLower
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| boolean | No | false | When set to This flag prevents reducing existing limits and ensures limits only increase when beneficial. Only applicable when the type is set to |
vertical:
cpu:
limit:
type: multiplier
multiplier: 2.0
onlyIfOriginalLower: trueCombining both flags:
When both onlyIfOriginalExist and onlyIfOriginalLower are set to true, the behavior matches Memory's Automatic mode: limits are only set when the workload originally had limits defined AND only when those original limits are lower than the calculated value.
vertical:
cpu:
limit:
type: multiplier
multiplier: 1.5
onlyIfOriginalExist: true
onlyIfOriginalLower: truevertical.cpu.optimization
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string | no | This configuration option can be used to disable CPU management for workloads that benefit from memory management only. The workload will then use CPU requests/limits configured in the template.
|
vertical:
cpu:
optimization: offvertical.memory
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
memory | object | No | - | Memory-specific scaling configuration. |
vertical:
memory:
target: max
lookBackPeriod: 24h
min: 128Mi
max: 2Gi
applyThresholdStrategy:
type: defaultAdaptive
overhead: 0.1vertical.memory.target
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string | No | "max" | Resource usage target:
|
vertical:
memory:
target: maxvertical.memory.lookBackPeriod
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| duration | No | "24h" | Historical resource usage data window to consider for recommendations (3h-168h). See Look-back Period. |
vertical:
memory:
lookBackPeriod: 24hvertical.memory.min
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
min | string | No | "10Mi" | Minimum resource limit. Uses standard Kubernetes memory notation (e.g., "2Gi", "1000Mi"). |
vertical:
memory:
min: 128Mivertical.memory.max
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
max | string | No | - | Maximum resource limit. Uses standard Kubernetes memory notation (e.g., "2Gi", "1000Mi"). |
vertical:
memory:
max: 2Givertical.memory.applyThreshold
Deprecation NoticeThe
applyThresholdconfiguration option is deprecated but still supported for backward compatibility. We strongly recommend migrating to the newapplyThresholdStrategyconfiguration format for future compatibility and access to the latest features. See applyThresholdStrategy.
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float | No | 0.1 | The relative difference required between current and recommended resource values to apply a change immediately:
|
vertical:
memory:
applyThreshold: 0.1vertical.memory.applyThresholdStrategy
Warning
applyThresholdandapplyThresholdStrategycannot be used simultaneously in a configuration as that will result in an error.applyThresholdStrategyis the latest and recommended configuration option.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
applyThresholdStrategy | object | No | - | Configuration for the strategy used to determine when recommendations should be applied. The strategy determines how the threshold percentage is calculated based on current resource requests. |
vertical:
memory:
applyThresholdStrategy:
type: customAdaptive # Using custom adaptive threshold
numerator: 0.1
exponent: 0.1
denominator: 2vertical.memory.applyThresholdStrategy.type
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string |
| "defaultAdaptive" | The type of threshold strategy to use:
|
vertical:
memory:
applyThresholdStrategy:
type: defaultAdaptive # Using default adaptive thresholdvertical.memory.applyThresholdStrategy.percentage
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float |
| The fixed percentage threshold to use. Value range: 0.01-2.5.
|
vertical:
memory:
applyThresholdStrategy:
type: percentage # Using fixed percentage threshold
percentage: 0.3 # 30% thresholdvertical.memory.applyThresholdStrategy.numerator
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float |
| 0.5 | Affects the vertical stretch of the threshold function. Lower values create smaller thresholds.
|
vertical:
memory:
applyThresholdStrategy:
type: customAdaptive # Using custom adaptive threshold
numerator: 0.1
exponent: 0.1
denominator: 2vertical.memory.applyThresholdStrategy.denominator
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float |
| 1 | Affects threshold sensitivity for small workloads. Values close to
|
vertical:
memory:
applyThresholdStrategy:
type: customAdaptive
numerator: 0.1
exponent: 0.1
denominator: 2vertical.cpu.applyThresholdStrategy.exponent
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float |
| 1 | Controls how quickly the threshold decreases for larger workloads. Lower values prevent extremely small thresholds for large resources.
|
vertical:
memory:
applyThresholdStrategy:
type: customAdaptive
numerator: 0.1
exponent: 0.1
denominator: 2vertical.memory.overhead
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float | No | 0.1 | Additional resource buffer when applying recommendations (0.0-2.5, e.g., 0.1 = 10%). If a 10% buffer is configured, the issued recommendation will have +10% added to it so that the workload can handle further increased resource demand. |
vertical:
memory:
overhead: 0.1vertical.memory.limit
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| object | No | Configuration for container memory limit scaling. The default behavior when not specified:
|
vertical:
memory:
limit:
type: multiplier
multiplier: 1.5vertical.memory.limit.type
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string | *Yes | Type of limit scaling to apply:
*If using the |
vertical:
memory:
limit:
type: keepLimits vertical.memory.limit.multiplier
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| float |
| Value to multiply the requests by to set the limit on the workload. The calculation is: *Required when type is set to |
vertical:
memory:
limit:
type: multiplier
multiplier: 1.5vertical.memory.optimization
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string | no | This configuration option can be used to disable memory management for workloads that benefit from CPU management only (e.g., Java workloads with a fixed heap size). The workload will then use memory requests/limits configured in the template.
|
vertical:
memory:
optimization: offvertical.predictiveScaling
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
predictiveScaling | object | No | - | Predictive scaling configuration for CPU. |
vertical:
predictiveScaling:
cpu:
enabled: truevertical.predictiveScaling.cpu
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
cpu | object | No | - | CPU-specific predictive scaling settings. |
vertical:
predictiveScaling:
cpu:
enabled: truevertical.predictiveScaling.cpu.enabled
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| boolean | No | false | Enable predictive scaling for CPU resources. When enabled, the system forecasts CPU usage based on historical patterns and generates proactive recommendations. Requires Predictive scaling can be enabled on any workload via annotations, even if it is not currently eligible for scaling in this manner. The system will automatically activate predictive scaling once the workload becomes predictable and will seamlessly revert to standard scaling if the patterns are lost. This allows preemptive enablement without monitoring for eligibility. See Predictive workload scaling for more information. |
vertical:
predictiveScaling:
cpu:
enabled: truevertical.downscaling
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
downscaling | object | No | - | Downscaling behavior override. |
vertical:
downscaling:
applyType: immediatevertical.downscaling.applyType
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string | No | Default is taken from the vertical scaling policy controlling the workload. | Override application mode:
|
vertical:
downscaling:
applyType: immediatevertical.memoryEvent
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
memoryEvent | object | No | - | Memory event behavior override. |
vertical:
memoryEvent:
applyType: immediatevertical.memoryEvent.applyType
This configuration option is fully compatible with other applyType options and is meant to be used in combination with them. This allows for fine-grained control over both upscaling and downscaling. Here's how they interact:
- If both configuration options are set to the same value (both
immediateor bothdeferred), the behavior remains unchanged. - If
vertical.downscaling.applyTypeis set todeferredandvertical.memoryEvent.applyTypeis set toimmediate:- Upscaling operations will be applied immediately.
- Downscaling operations will be deferred to natural pod restarts.
- If
vertical.downscaling.applyTypeis set toimmediateandvertical.memoryEvent.applyTypeis set todeferred:- Upscaling operations will be deferred to natural pod restarts.
- Downscaling operations will be applied immediately.
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string |
| Default is taken from the vertical scaling policy controlling the workload. | Override application mode for memory-related events (OOM kills, pressure):
|
vertical:
memoryEvent:
applyType: immediatevertical.containers
Configuration object that contains container-specific settings.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| containers | object | No | - | Container configuration mapping. |
vertical:
containers:vertical.containers.{container_name}
Configuration object that contains resource constraints for a specific container. Replace {container_name} with the name of your container.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| {container_name} | object | No | - | Container resource configuration object. Has to be the name of the container for which resources are being configured. |
vertical:
containers:
{container_name}:
NoteContainer constraints apply to application containers (
spec.containers[]) and native sidecar containers (spec.initContainers[]withrestartPolicy: Always). Traditional initContainers that run during pod startup are not optimized by Workload Autoscaler.
vertical.containers.{container_name}.cpu
Container CPU constraints. Set minimum and maximum CPU limits for a specific container to define the workload autoscaler's scaling range.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| max | string | No | - | The upper limit for the recommendation. Uses standard Kubernetes CPU notation (e.g., "1000m" or "1"). Recommendations won't exceed this value. |
| min | string | No | - | The lower limit for the recommendation. Uses standard Kubernetes CPU notation (e.g., "1000m" or "1"). Min cannot be greater than max. |
vertical:
containers:
{container_name}:
cpu:
min: 10m
max: 1000mvertical.containers.{container_name}.memory
Container memory constraints. Set minimum and maximum memory limits for a specific container to define the workload autoscaler's scaling range.
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| min | string | No | - | Minimum resource limit. Uses standard Kubernetes memory notation (e.g., "2Gi", "1000Mi"). |
| max | string | No | - | Maximum resource limit. Uses standard Kubernetes memory notation (e.g., "2Gi", "1000Mi"). |
vertical:
containers:
{container_name}:
memory:
min: 10Mi
max: 2048MirolloutBehavior
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
rolloutBehavior | object | No | - | Configuration for controlling how recommendations are rolled out. |
rolloutBehavior:
type: NoDisruptionrolloutBehavior.type
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string |
| Controls how recommendation updates are rolled out:
|
rolloutBehavior:
type: NoDisruptionrolloutBehavior.preferOneByOne
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| boolean | No |
| When See Pod restart strategy for more information. |
rolloutBehavior:
type: NoDisruption
preferOneByOne: truehorizontal
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
horizontal | object | No | - | Horizontal scaling configuration. |
horizontal:
optimization: on
minReplicas: 1
maxReplicas: 10
scaleDown:
stabilizationWindow: 5m
shortAverage: 3mhorizontal.optimization
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string | Yes* | Enable horizontal scaling ("on"/"off").
|
horizontal:
optimization: onhorizontal.minReplicas
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
minReplicas | integer | Yes* | - | Minimum number of replicas. |
horizontal:
minReplicas: 1horizontal.maxReplicas
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
maxReplicas | integer | Yes* | - | Maximum number of replicas. |
horizontal:
maxReplicas: 10horizontal.scaleDown
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
scaleDown | object | No | - | Houses scaledown cofiguration options. |
horizontal.scaleDown.stabilizationWindow
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| duration |
| "5m" | Cooldown period between scale-downs.
|
horizontal:
scaleDown:
stabilizationWindow: 5m*Required if the parent object is present in the configuration.
containersGrouping
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
containersGrouping | array | No | - | Rules for grouping dynamically generated containers with similar naming patterns. |
containersGrouping:
- key: name
operator: contains
values: ["data-processor"]
into: data-processorcontainersGrouping.[].key
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
key | string | *Yes | - | The attribute used to match containers. Currently, only supports name which refers to the container name property. |
containersGrouping.[].operator
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
operator | string | *Yes | - | Defines how the key is evaluated against the values list. Currently, only supports contains. |
containersGrouping.[].values
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
values | array | *Yes | - | A list of string values used for matching against the key with the specified operator. Must contain at least one item. |
containersGrouping.[].into
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
into | string | *Yes | - | The target container name into which matching containers should be grouped. |
Example usage
See Container Grouping for Dynamic Containers.
*Required if the parent object is present in the configuration.
schedule
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
schedule | object | No | - | Controls whether a custom workload is treated as job-like (sporadic execution) or continuous (always running) for optimization purposes. |
schedule:
type: jobLikeschedule.type
Field | Type | Required | Default | Description |
|---|---|---|---|---|
| string | No | Explicitly sets whether the custom workload should be treated as job-like or continuous:
|
schedule:
type: jobLike # For sporadic workloads like batch jobs
ImportantThe
schedule.typeconfiguration only applies to custom job-like workloads identified by theworkloads.cast.ai/custom-workloadlabel. Native Kubernetes Jobs with this label are always treated as job-like, and standard workload types (Deployments, StatefulSets, etc.) are always treated as continuous.
Legacy Annotation SupportFor documentation on the legacy annotation format, which is now deprecated, see the Legacy Annotations Reference page .
Migration Guide
NoteThe annotations V2 structure cannot be combined with deprecated annotations V1. When the annotation
workloads.cast.ai/configurationis detected, the workload is considered to be configured by using that annotation and all other annotations starting withworkloads.cast.aiwill be ignored.
To migrate from v1 to v2 annotations:
- Remove all individual legacy
workloads.cast.ai/*annotations - Add the new
workloads.cast.ai/configurationannotation - Move all settings into the YAML structure under the new annotation
For example, these v1 annotations:
workloads.cast.ai/vertical-autoscaling: "on"
workloads.cast.ai/cpu-target: "p80"
workloads.cast.ai/memory-max: "2Gi"Would become:
workloads.cast.ai/configuration: |
vertical:
optimization: on
cpu:
target: p80
memory:
max: 2GiUpdated 15 days ago
