Workload Resources

A Workload represents an application or task running on your infrastructure. Workloads are Kubernetes resources automatically created by AIWorkloads, which are built from three types of building blocks called Definitions:

• Components - Define what runs, such as a web server, a database, or a batch job.

• Traits - Modify how it runs, such as scaling behavior, health checks, and resource limits.

• Policies - Specify where and how Workloads get deployed, controlling placement and environment-specific overrides.

Workloads are automatically classified into two types based on their components.

Type	Description	Examples
Application	Long-running services that stay up continuously.	Web servers, APIs, databases
Task	Jobs that run once or on a schedule, then complete.	Data migrations, batch processing, backups

A Workload is classified as application if it contains any application-type components; otherwise, it's classified as task.

Each Workload is a concrete instantiation of a particular Workload Profile, realized as a Workload custom resource on the PaletteAI spoke clusters.

Workload Profiles

A Workload Profile is a reusable template that defines how an application should be configured, allowing you to decouple the modeling and deployment phases of the application lifecycle. Similar to a blueprint, you configure it once, then deploy it multiple times to different environments.

Under the hood, each Workload Profile is a WorkloadProfile custom resource on the PaletteAI control plane, also known as the hub cluster. Workload Profiles are constructed using the same spec (same Definitions) as Workloads, but have differing metadata and status fields.

Workload Profile Revisions

Every time you create or edit a Workload Profile, PaletteAI automatically saves a revision, or snapshot, of that Workload Profile version as a DefinitionRevision resource. This allows you to track changes over time, roll back to previous versions, and pin deployments to specific versions for stability

Each revision is identified by a version number (such as @v1 or @v1.2.0) and a unique hash. The status.latestRevision field on a Workload Profile tracks the most recent revision.

When unpinned Definitions referenced by a Workload Profile are updated, Workload Deployments referencing those Definitions are updated during the next reconciliation cycle to reflect the resources rendered from the latest version. You can opt out of this behavior by pinning a Definition to a specific version.

Example

The following sample Workload Profile contains a webservice component with two traits: scaler and hpa. When deployed via a Workload Deployment, it produces a Kubernetes Deployment, Service, and Horizontal Pod Autoscaler.

apiVersion: spectrocloud.com/v1beta1
kind: WorkloadProfile
metadata:
  name: nginx-demo
spec:
  workload:
    components:
      - name: nginx-demo # Unique name for this component
        type: webservice@v1.0.0 # Component type with pinned version
        properties:
          cpu: '0.5' # CPU request
          memory: 1024Mi # Memory request
          image: nginx:latest # Container image
          ports:
            - containerPort: 80
              expose: true # Make accessible outside the cluster
        traits:
          - type: hpa@v1.0.0 # Horizontal Pod Autoscaler trait
            properties:
              min: 1 # Minimum replicas
              max: 10 # Maximum replicas
              cpu:
                type: Utilization
                value: 50 # Scale up when CPU > 50%
          - type: scaler@v1.0.0 # Manual scaling trait
            properties:
              replicas: 1 # Starting replica count

Workload Deployments

Workload Deployments manage the lifecycle of Workloads and track their statuses. They are composed of metadata and a spec that includes a Workload Profile reference, a target Workload specification (name, namespace, and optional metadata), an Environment to determine replication and scheduling, and optional Variables for templating.

The Definitions within a Workload's spec are rendered by PaletteAI into Kubernetes resources and applied to one or more Kubernetes clusters within a multi-cluster. The specific Kubernetes clusters selected for a Workload Deployment are dictated by the selected environment and its inputs.

Under the hood, a Workload Deployment is a WorkloadDeployment custom resource on the PaletteAI hub.

Key Fields

Field	Purpose
workloadProfileRef	Which Workload Profile template to use.
environmentRef	Which Environment (target clusters) to deploy to.
workload.name	Name for the deployed workload.
workload.namespace	Kubernetes namespace for the Workload.
variables	Optional overrides for this deployment.

Variables

Variables let you customize deployments without changing the underlying Workload Profile. For example, you might use different database connection strings for dev and production.

Variables take precedence in the following order:

1. Variables in the WorkloadDeployment's spec.variables field.

2. Variables in the project's VariableSet (named mural-variables).

3. Variables in the system definition namespace's VariableSet.

info

If a variable is marked as Locked in a VariableSet, it cannot be overridden by Workload Deployment variables. This is useful for enforcing organization-wide settings.

Workload Deployment Versions

By default, Workload Deployments are automatically updated whenever the underlying content of their Workload Profile or Environment is updated. You may also pin the version of a Workload Profile or Environment referenced by a Workload Deployment. Versioning follows the same pattern as other PaletteAI definitions, supporting both basic versioning (for example, @v1) and semantic versioning (for example, @v1.2.0) in the environmentRef and workloadProfileRef fields. The versioning type (basic or semantic) is configured globally via the global.featureFlags.versioningType Helm value.