Skip to main content
To enable Thoras to manage or recommend scaling for your workload, you must register an AIScaleTarget Custom Resource (CRD) in your Kubernetes cluster. This guide will walk you through doing this by applying an AIScaleTarget resource with kubectl.

​
Prerequisites

​
0. (Optional) Auto-configure AIScaleTargets using the dashboard

On a fresh installation, Thoras can auto-discover workloads and make suggestions to auto-populate AIScaleTargets in the cluster. This enables metric collection and resource recommendations for the selected workloads (see quickstart guide). Eventually you will probably want to integrate your AIScaleTarget configurations into your delivery pipelines, but the auto-populate feature is a particularly useful way to try out the product without having to manage any configuration.

​
1. Define Initial AIScaleTarget Custom Resource

Create a new file named my-ast.yaml 
apiVersion: thoras.ai/v1
kind: AIScaleTarget
metadata:
  name: {{YOUR_AST_NAME}}
  namespace: {{YOUR_NAMESPACE}}
spec:
  model:
    forecast_blocks: 15m
    forecast_cron: "*/15 * * * *"
  scaleTargetRef:
    kind: Deployment
    name: {{YOUR_AST_NAME}}
  horizontal:
    mode: recommendation
  • metadata.name: The name for your AIScaleTarget resource (should match your workload name for clarity).
  • metadata.namespace: The namespace where your workload is running.
  • spec.scaleTargetRef: Points to the Kubernetes resource (usually a Deployment) you want to scale.
  • spec.model.forecast_blocks: How far into the future to forecast
  • spec.model.forecast_cron: How often to make a forecast.

​
2. Apply the AIScaleTarget Using the CLI

Use kubectl apply to register the AIScaleTarget with your cluster: 
kubectl apply -f my-ast.yaml
You should see output like: 
aiscaletarget.thoras.ai/my-name created

​
3. Verify the AIScaleTarget

Check that your AIScaleTarget was created: 
kubectl get aiscaletarget -n my-namespace
To see details: 
kubectl describe aiscaletarget my-app -n my-namespace
Note: An existing AIScaleTarget can be exported to a YAML for version control or editing with: 
kubectl get aiscaletarget <name> -n <namespace> -o yaml > my-ast.yaml

​
Using Label Selectors to Target Multiple Workloads

Instead of targeting a single workload by name with scaleTargetRef, you can use selector to apply the same vertical scaling policy to multiple workloads that share common pod labels.

​
When to Use Label Selectors

Label selectors are useful when you want to:
  • Scale a workload that uses a blue/green deployment strategy
  • Scale workloads dynamically based on labels without hardcoding specific names
  • Manage scaling configurations at a higher level of abstraction

​
Example: Targeting Multiple Workloads by Label

Create an AIScaleTarget using a label selector: 
apiVersion: thoras.ai/v1
kind: AIScaleTarget
metadata:
  name: production-services
  namespace: {{YOUR_NAMESPACE}}
spec:
  selector:
    matchLabels:
      app: my-service
      environment: production
  model:
    forecast_blocks: 15m
    forecast_cron: "*/15 * * * *"
  vertical:
    containers:
      - name: {{CONTAINER_NAME}}
        cpu:
          lowerbound: 20m
          upperbound: 1
        memory:
          lowerbound: 50Mi
          upperbound: 2G
    mode: recommendation
    in_place_resizing:
      enabled: true
This configuration targets all Deployments, StatefulSets, and Rollouts in the namespace whose pods have both app: my-service and environment: production labels.

​
Important Constraints

  • selector and scaleTargetRef are mutually exclusive—use one or the other
  • Horizontal scaling is not supported with selector—omit spec.horizontal entirely
  • Only vertical scaling is supported when using label selectors
  • All targeted workloads must be in the same namespace as the AIScaleTarget
  • Pods must be managed by a Deployment, StatefulSet, or Argo Rollout. Standalone pods or other controller types are not supported.

​
Behavior in Autonomous Mode

When using selector in autonomous mode:
  1. Thoras identifies all matching pod controllers in the namespace
  2. When the forecaster suggests new resource requests, Thoras updates each matching controller one by one
  3. If in_place_resizing.enabled: true, pods are resized in place when possible (Kubernetes 1.33+)
  4. If in-place resizing is not enabled or fails, pods are restarted with the new resource requests