Annotations reference

All Workload Autoscaler settings are available by adding annotations to the workload controller. Annotations are the only way to override vertical scaling settings for individual workloads — the Cast AI console does not support per-workload setting overrides. 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
        anomalyDetection:
          cpuPressure:
            cpuStallThresholdPercentage: 30.0
            minPressuredPodPercentage: 20.0
        excludedContainers:
          - istio-proxy
        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
        jvm:
          enabled: true
          autoInstrument: true
      hpaConverters:
        - type: AverageValueFromOriginalRequests
      rolloutBehavior:
        type: NoDisruption
        preferOneByOne: true
        delaySeconds: 120
      horizontal:
        optimization: on
        minReplicas: 5
        maxReplicas: 10
        scaleDown:
          stabilizationWindow: 5m
      containersGrouping:
        - key: name
          operator: contains
          values: ["data-processor"]
          into: data-processor

Labels

In addition to the workloads.cast.ai/configuration annotation, Workload Autoscaler recognizes the following label on workload controllers and pods:

Configuration Structure

Below is a configuration structure reference for setting up a workload to be controlled by annotations.

📘

Note

workloads.cast.ai/configuration has 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 assigns the workload to system default policies based on workload type: resiliency for StatefulSets and balanced for all other workloads.

scalingPolicyName: custom-policy

Fallback for invalid policy names

If the scalingPolicyName value does not match any existing scaling policy, the workload falls back to system default policies:

• StatefulSets: resiliency
• All other workloads: balanced

When this fallback occurs, the Cast AI Console displays a warning status on the workload in the Optimization page, such as: Could not find scaling policy by name '<policy-name>'. To resolve this, update the annotation to reference a valid scaling policy name.

vertical

vertical:
  optimization: on
  applyType: immediate
  antiAffinity:
    considerAntiAffinity: false
  startup:
    period: 5m
  confidence:
    threshold: 0.5
  excludedContainers:
    - istio-proxy

vertical.optimization

vertical:
  optimization: on

vertical.applyType

vertical:
  applyType: immediate

vertical.antiAffinity

vertical:
  antiAffinity:
    considerAntiAffinity: false

vertical.antiAffinity.considerAntiAffinity

vertical:
  antiAffinity:
    considerAntiAffinity: false

vertical.startup

vertical:
  startup:
    period: 5m

vertical.startup.period

vertical:
  startup:
    period: 5m # Example: ignore first 5 minutes of metrics

vertical:
  startup:
    period: 0s # Disable startup metrics ignore period

vertical.startup.twoPhaseRecommendations

vertical:
  startup:
    period: 30s
    twoPhaseRecommendations:
      enabled: true

vertical.startup.twoPhaseRecommendations.enabled

vertical:
  startup:
    period: 30s
    twoPhaseRecommendations:
      enabled: true

vertical.startup.twoPhaseRecommendations.requestsOnStartup

vertical:
  startup:
    period: 30s
    twoPhaseRecommendations:
      enabled: true
      requestsOnStartup:
        cpu: 500m
        memory: 256Mi

vertical.startup.twoPhaseRecommendations.requestsOnStartup.cpu

vertical:
  startup:
    period: 30s
    twoPhaseRecommendations:
      enabled: true
      requestsOnStartup:
        cpu: 500m # memory falls back to original pod request

vertical.startup.twoPhaseRecommendations.requestsOnStartup.memory

vertical:
  startup:
    period: 30s
    twoPhaseRecommendations:
      enabled: true
      requestsOnStartup:
        memory: 256Mi # cpu falls back to original pod request

vertical.confidence

vertical:
  confidence:
    threshold: 0.5
    required: false

vertical.confidence.required

vertical:
  confidence:
    required: true

vertical.confidence.threshold

vertical:
  confidence:
    threshold: 0.5

vertical.anomalyDetection

vertical:
  anomalyDetection:
    cpuPressure:
      cpuStallThresholdPercentage: 10.0
      minPressuredPodPercentage: 50.0

vertical.anomalyDetection.cpuPressure

vertical:
  anomalyDetection:
    cpuPressure:
      cpuStallThresholdPercentage: 10.0
      minPressuredPodPercentage: 50.0

vertical.anomalyDetection.cpuPressure.cpuStallThresholdPercentage

vertical:
  anomalyDetection:
    cpuPressure:
      cpuStallThresholdPercentage: 30.0 # 30% stall threshold

vertical.anomalyDetection.cpuPressure.minPressuredPodPercentage

vertical:
  anomalyDetection:
    cpuPressure:
      minPressuredPodPercentage: 20.0 # Scale when 20% of pods are stalling

vertical.resourceStrategy

vertical:
  resourceStrategy:
    type: nodeAllocatablePercentage
    nodeAllocatablePercentage:
      cpuPercent: 5
      memoryPercent: 2

At this (workload) level, the strategy applies to every container in the pod that already has CPU or memory requests in its spec. To size a container that has no requests defined, or to use different percentages per container, set it at the container level.

vertical.resourceStrategy.type

vertical:
  resourceStrategy:
    type: nodeAllocatablePercentage

vertical.resourceStrategy.nodeAllocatablePercentage

vertical:
  resourceStrategy:
    type: nodeAllocatablePercentage
    nodeAllocatablePercentage:
      cpuPercent: 5
      memoryPercent: 2

vertical.resourceStrategy.nodeAllocatablePercentage.cpuPercent

vertical:
  resourceStrategy:
    type: nodeAllocatablePercentage
    nodeAllocatablePercentage:
      cpuPercent: 5

vertical.resourceStrategy.nodeAllocatablePercentage.memoryPercent

vertical:
  resourceStrategy:
    type: nodeAllocatablePercentage
    nodeAllocatablePercentage:
      memoryPercent: 2

vertical.cpu

vertical:
  cpu:
    target: p80
    lookBackPeriod: 24h
    min: 100m
    max: 1000m
    applyThresholdStrategy:
    	type: defaultAdaptive
    overhead: 0.1

vertical.cpu.target

vertical:
  cpu:
    target: p80

vertical.cpu.lookBackPeriod

vertical:
  cpu:
    lookBackPeriod: 24h

vertical.cpu.constraints

Defines minimum and maximum CPU bounds for the autoscaler. Two formats are supported:

• constraints object (required when using percentageOfOriginal): specifies a typed constraint with type and value fields.
• Legacy flat format (min/max as strings): still supported for constant values and not planned for deprecation.

vertical.cpu.constraints.min

vertical.cpu.constraints.max

Same fields as vertical.cpu.constraints.min.

vertical:
  cpu:
    constraints:
      min:
        type: percentageOfOriginal
        value: 90
      max:
        type: constant
        value: 2000m

vertical:
  cpu:
    min: 100m
    max: 2000m

📘

Note

percentageOfOriginal requires the workload to have defined resource requests. Not supported for custom workloads or injected containers. If requests are not defined, the constraint is treated as having no limit set.

vertical.cpu.applyThreshold

🚧

Deprecation Notice

The applyThreshold configuration option is deprecated but still supported for backward compatibility. We strongly recommend migrating to the new applyThresholdStrategy configuration format for future compatibility and access to the latest features. See applyThresholdStrategy.

vertical:
  cpu:
    applyThreshold: 0.1

vertical.cpu.applyThresholdStrategy

🚧

Warning

applyThreshold and applyThresholdStrategy cannot be used simultaneously in a configuration as that will result in an error. applyThresholdStrategy is the latest and recommended configuration option.

vertical:
  cpu:
    applyThresholdStrategy:
      type: defaultAdaptive

vertical.cpu.applyThresholdStrategy.type

vertical:
  cpu:
    applyThresholdStrategy:
      type: defaultAdaptive # Using default adaptive threshold

vertical.cpu.applyThresholdStrategy.percentage

vertical:
  cpu:
    applyThresholdStrategy:
      type: percentage # Using fixed percentage threshold
      percentage: 0.3 # 30% threshold

vertical.cpu.applyThresholdStrategy.numerator

vertical:
  cpu:
    applyThresholdStrategy:
      type: customAdaptive # Using custom adaptive threshold
      numerator: 0.1
      exponent: 0.1
      denominator: 2

vertical.cpu.applyThresholdStrategy.denominator

vertical:
  cpu:
    applyThresholdStrategy:
      type: customAdaptive
      numerator: 0.1
      exponent: 0.1
      denominator: 2

vertical.cpu.applyThresholdStrategy.exponent

vertical:
  cpu:
    applyThresholdStrategy:
      type: customAdaptive
      numerator: 0.1
      exponent: 0.1
      denominator: 2

vertical.cpu.overhead

vertical:
  cpu:
    overhead: 0.1

vertical.cpu.limit

📘

Relationship to UI options

The annotation fields in this section correspond to the Workload resource limits options in the CAST AI console. See Workload resource limits for the UI-level description of each mode, including how the Semi-automatic (CPU) and Automatic (memory) shortcuts map to specific type, multiplier, onlyIfOriginalExist, and onlyIfOriginalLower combinations.

vertical:
  cpu:
    limit:
      type: multiplier
      multiplier: 2.0

vertical.cpu.limit.type

vertical:
  cpu:
    limit:
      type: keepLimits

vertical.cpu.limit.multiplier

vertical:
  cpu:
    limit:
      type: multiplier
      multiplier: 2.0

vertical.cpu.limit.onlyIfOriginalExist

vertical:
  cpu:
    limit:
      type: multiplier
      multiplier: 2.0
      onlyIfOriginalExist: true

vertical.cpu.limit.onlyIfOriginalLower

vertical:
  cpu:
    limit:
      type: multiplier
      multiplier: 2.0
      onlyIfOriginalLower: true

Combining 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: true

vertical.cpu.optimization

vertical:
  cpu:
    optimization: off

vertical.memory

vertical:
  memory:
    target: max
    lookBackPeriod: 24h
    min: 128Mi
    max: 2Gi
    applyThresholdStrategy:
    	type: defaultAdaptive
    overhead: 0.1

vertical.memory.target

vertical:
  memory:
    target: max

vertical.memory.lookBackPeriod

vertical:
  memory:
    lookBackPeriod: 24h

vertical.memory.constraints

Defines minimum and maximum memory bounds for the autoscaler. Two formats are supported:

• constraints object (required when using percentageOfOriginal): specifies a typed constraint with type and value fields.
• Legacy flat format (min/max as strings): still supported for constant values and not planned for deprecation.

vertical.memory.constraints.min

vertical.memory.constraints.max

Same fields as vertical.memory.constraints.min. Note: This does not cap the memory limit directly. To control memory limits, see vertical.memory.limit.

vertical:
  memory:
    constraints:
      min:
        type: constant
        value: 128Mi
      max:
        type: percentageOfOriginal
        value: 150

vertical:
  memory:
    min: 128Mi
    max: 2Gi

📘

Note

percentageOfOriginal requires the workload to have defined resource requests. Not supported for custom workloads or injected containers. If requests are not defined, the constraint is treated as having no limit set.

vertical.memory.applyThreshold

🚧

Deprecation Notice

The applyThreshold configuration option is deprecated but still supported for backward compatibility. We strongly recommend migrating to the new applyThresholdStrategy configuration format for future compatibility and access to the latest features. See applyThresholdStrategy.

vertical:
  memory:
    applyThreshold: 0.1

vertical.memory.applyThresholdStrategy

🚧

Warning

applyThreshold and applyThresholdStrategy cannot be used simultaneously in a configuration as that will result in an error. applyThresholdStrategy is the latest and recommended configuration option.

vertical:
  memory:
    applyThresholdStrategy:
      type: customAdaptive # Using custom adaptive threshold
      numerator: 0.1
      exponent: 0.1
      denominator: 2

vertical.memory.applyThresholdStrategy.type

vertical:
  memory:
    applyThresholdStrategy:
      type: defaultAdaptive # Using default adaptive threshold

vertical.memory.applyThresholdStrategy.percentage

vertical:
  memory:
    applyThresholdStrategy:
      type: percentage # Using fixed percentage threshold
      percentage: 0.3 # 30% threshold

vertical.memory.applyThresholdStrategy.numerator

vertical:
  memory:
    applyThresholdStrategy:
      type: customAdaptive # Using custom adaptive threshold
      numerator: 0.1
      exponent: 0.1
      denominator: 2

vertical.memory.applyThresholdStrategy.denominator

vertical:
  memory:
    applyThresholdStrategy:
      type: customAdaptive
      numerator: 0.1
      exponent: 0.1
      denominator: 2

vertical.cpu.applyThresholdStrategy.exponent

vertical:
  memory:
    applyThresholdStrategy:
      type: customAdaptive
      numerator: 0.1
      exponent: 0.1
      denominator: 2

vertical.memory.overhead

vertical:
  memory:
    overhead: 0.1

vertical.memory.limit

vertical:
  memory:
    limit:
      type: multiplier
      multiplier: 1.5

vertical.memory.limit.type

vertical:
  memory:
    limit:
      type: keepLimits

vertical.memory.limit.multiplier

vertical:
  memory:
    limit:
      type: multiplier
      multiplier: 1.5

vertical.memory.optimization

vertical:
  memory:
    optimization: off

vertical.excludedContainers

Specifies container names to exclude from vertical autoscaling optimization. Excluded containers retain their current resource settings and are not scaled by the Workload Autoscaler. Recommendations are still generated and visible in event logs and the workload detail view.

vertical:
  excludedContainers:
    - istio-proxy
    - logging-agent

📘

Note

excludedContainers targets containers explicitly defined in your pod spec, such as application containers or native Kubernetes sidecar containers.

vertical.predictiveScaling

vertical:
  predictiveScaling:
    cpu:
      enabled: true

vertical.predictiveScaling.cpu

vertical:
  predictiveScaling:
    cpu:
      enabled: true

vertical.predictiveScaling.cpu.enabled

vertical:
  predictiveScaling:
    cpu:
      enabled: true

vertical.downscaling

vertical:
  downscaling:
    applyType: immediate

vertical.downscaling.applyType

vertical:
  downscaling:
    applyType: immediate

vertical.memoryEvent

vertical:
  memoryEvent:
    applyType: immediate

vertical.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:

1. If both configuration options are set to the same value (both immediate or both deferred), the behavior remains unchanged.
2. If vertical.downscaling.applyType is set to deferred and vertical.memoryEvent.applyType is set to immediate:
   • Upscaling operations will be applied immediately.
   • Downscaling operations will be deferred to natural pod restarts.
3. If vertical.downscaling.applyType is set to immediate and vertical.memoryEvent.applyType is set to deferred:
   • Upscaling operations will be deferred to natural pod restarts.
   • Downscaling operations will be applied immediately.

vertical:
  memoryEvent:
    applyType: immediate

vertical.containers

Configuration object that contains container-specific settings.

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.

vertical:
  containers:
    ? { container_name }

📘

Note

Container constraints apply to application containers (spec.containers[]) and native sidecar containers (spec.initContainers[] with restartPolicy: Always). Traditional initContainers that run during pod startup are not optimized by Workload Autoscaler.

vertical.containers.{container_name}.resourceStrategy

Container-level sizing strategy. Sets a resource strategy for a specific container, overriding vertical.resourceStrategy for that container. Supports the same type and nodeAllocatablePercentage fields as the workload-level strategy. See Node-aware DaemonSet sizing.

Setting the strategy at the container level sizes only that container. It can also add requests to a container that has none in its pod spec. The workload-level strategy, by contrast, only applies to containers that already have requests.

vertical:
  containers:
    app:
      resourceStrategy:
        type: nodeAllocatablePercentage
        nodeAllocatablePercentage:
          cpuPercent: 30
          memoryPercent: 40

📘

Note

Container min/max constraints and the resource strategy are per container, but limits and lookBackPeriod are workload-level only. Per-container limit and lookBackPeriod settings are not supported and are silently ignored.

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. With the nodeAllocatablePercentage strategy, these constrain (clamp) the resolved percentage for this container. The percentageOfOriginal type is not yet supported at container level — only constant is. The constraints.min and constraints.max blocks are optional, but if specified, both type and value are required.

vertical:
  containers:
    { container_name }:
      cpu:
        constraints:
          min:
            type: constant
            value: 10m
          max:
            type: constant
            value: 1000m

vertical.containers.{container_name}.memory

Container memory request constraints. Set minimum and maximum memory requests for a specific container to define the workload autoscaler's scaling range. With the nodeAllocatablePercentage strategy, these constrain (clamp) the resolved percentage for this container. These values control requests only; memory limits are managed separately via vertical.memory.limit. The percentageOfOriginal type is not yet supported at container level — only constant is. The constraints.min and constraints.max blocks are optional, but if specified, both type and value are required.

vertical:
  containers:
    { container_name }:
      memory:
        constraints:
          min:
            type: constant
            value: 10Mi
          max:
            type: constant
            value: 2048Mi

vertical.containers.{container_name}.jvm

Container-level JVM optimization settings. These override the workload-level vertical.jvm settings for a specific container, allowing you to enable or disable JVM optimization and auto-instrumentation on individual containers within a multi-container pod. For details on JVM optimization, see JVM workload optimization.

vertical:
  containers:
    { container_name }:
      jvm:
        enabled: true
        autoInstrument: true

vertical.containers.{container_name}.jvm.enabled

vertical:
  containers:
    { container_name }:
      jvm:
        enabled: true

vertical.containers.{container_name}.jvm.autoInstrument

vertical:
  containers:
    { container_name }:
      jvm:
        autoInstrument: true

vertical.excludedContainers

Specifies container names to exclude from vertical autoscaling. Excluded containers retain their current resource settings and are not scaled by the Workload Autoscaler. Recommendations are still generated and visible, but not applied.

vertical:
  excludedContainers:
    - istio-proxy
    - logging-agent

📘

Note

excludedContainers targets containers explicitly defined in your pod spec, such as application containers or native Kubernetes sidecar containers.

vertical.jvm

JVM-specific optimization settings for Java workloads. When enabled, the Workload Autoscaler uses actual JVM runtime data (heap usage, GC behavior, thread count) to generate memory recommendations instead of relying on standard Kubernetes container memory metrics. For a full explanation of JVM optimization, auto-instrumentation, prerequisites, and troubleshooting, see JVM workload optimization.

vertical:
  jvm:
    enabled: true
    autoInstrument: true

vertical.jvm.enabled

vertical:
  jvm:
    enabled: true

vertical.jvm.autoInstrument

vertical:
  jvm:
    autoInstrument: true

vertical.hpaConverters

vertical:
  hpaConverters:
    - type: AverageValueFromOriginalRequests

vertical.hpaConverters[].type

vertical:
  hpaConverters:
    - type: AverageValueFromOriginalRequests

📘

Note

The HPA converter applies to workloads that have their own HPA while Cast AI handles only vertical optimization. If Cast AI's horizontal autoscaling is also enabled for the workload, Cast AI already manages the HPA directly and the converter is not needed. Requires Workload Autoscaler version v1.0.11 or later.

rolloutBehavior

rolloutBehavior:
  type: NoDisruption
  preferOneByOne: true
  delaySeconds: 120

rolloutBehavior.type

rolloutBehavior:
  type: NoDisruption

rolloutBehavior.preferOneByOne

rolloutBehavior:
  preferOneByOne: true

rolloutBehavior.delaySeconds

rolloutBehavior:
  delaySeconds: 120

horizontal

When horizontal autoscaling is configured via annotations, Cast AI creates and manages a native Kubernetes HorizontalPodAutoscaler (autoscaling/v2) resource in the cluster. For concepts, supported workload types, and compatibility details, see Horizontal autoscaling.

horizontal:
  optimization: true
  useNative: true
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300

horizontal.optimization

horizontal:
  optimization: true

horizontal.useNative

horizontal:
  useNative: true

horizontal.takeOwnership

horizontal:
  takeOwnership: true

horizontal.minReplicas

horizontal:
  minReplicas: 2

horizontal.maxReplicas

horizontal:
  maxReplicas: 10

horizontal.metrics

horizontal:
  metrics:
    - type: resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

metrics[].type

metrics[].resource.name

metrics[].resource.target.type

metrics[].resource.target.averageUtilization

metrics:
  - type: resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

metrics[].resource.target.averageValue

metrics[].resource.target.value

horizontal.behavior

horizontal:
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      selectPolicy: Max
      tolerance: "0.1"
      policies:
        - type: Pods
          value: 4
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      selectPolicy: Min
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

horizontal.behavior.scaleUp / horizontal.behavior.scaleDown

The scaleUp and scaleDown objects share the same structure. The following fields apply to both.

behavior.direction.stabilizationWindowSeconds

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300

behavior.direction.selectPolicy

behavior.direction.tolerance

behavior:
  scaleUp:
    tolerance: "0.1"

behavior.direction.policies

policies[].type

policies[].value

policies[].periodSeconds

policies:
  - type: Pods
    value: 4
    periodSeconds: 60
  - type: Percent
    value: 100
    periodSeconds: 60

(Deprecated) legacy horizontal fields

🚧

Deprecated

The following fields apply only to legacy horizontal scaling. They are not compatible with native HPA mode (useNative: true). New configurations should use the fields documented in the horizontal section above. To migrate existing workloads, see Migrate from legacy horizontal scaling.

When using legacy Cast AI horizontal scaling (without useNative: true), the horizontal block uses the following structure:

horizontal:
  optimization: on
  minReplicas: 1
  maxReplicas: 10
  scaleDown:
    stabilizationWindow: 5m
  shortAverage: 3m

The minReplicas and maxReplicas fields work identically to the native HPA configuration documented above. The fields below are specific to legacy mode.

horizontal.optimization (legacy)

horizontal:
  optimization: on

horizontal.scaleDown.stabilizationWindow (legacy)

horizontal:
  scaleDown:
    stabilizationWindow: 5m

horizontal.shortAverage (legacy)

horizontal:
  shortAverage: 3m

containersGrouping

containersGrouping:
  - key: name
    operator: contains
    values: ["data-processor"]
    into: data-processor

containersGrouping.[].key

containersGrouping.[].operator

containersGrouping.[].values

containersGrouping.[].into

Example usage

See Container Grouping for Dynamic Containers.

*Required if the parent object is present in the configuration.

schedule

schedule:
  type: jobLike

schedule.type

schedule:
  type: jobLike # For sporadic workloads like batch jobs

🚧

Important

The schedule.type configuration only applies to custom job-like workloads identified by the workloads.cast.ai/custom-workload label. 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 Support

For documentation on the legacy annotation format, which is now deprecated, see the Legacy Annotations Reference page .

Migration Guide

📘

Note

The annotations V2 structure cannot be combined with deprecated annotations V1. When the annotation workloads.cast.ai/configuration is detected, the workload is considered to be configured by using that annotation and all other annotations starting with workloads.cast.ai will be ignored.

To migrate from v1 to v2 annotations:

1. Remove all individual legacy workloads.cast.ai/* annotations
2. Add the new workloads.cast.ai/configuration annotation
3. 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: 2Gi