Workload Resources

A Workload represents an application or task that runs on your infrastructure. PaletteAI creates Workloads from AIWorkload resources by using three 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.

PaletteAI classifies Workloads 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 is 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. It separates the modeling and deployment phases of the application lifecycle. You configure it once and then deploy it many times in 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 use the same specification as Workloads, including the same Definitions, but they use different metadata and status fields.

Components within a Workload Profile can reference Helm charts sourced from Repositories configured at the Project level. Repositories are Project-scoped resources that provide Helm charts for use in Workload Profiles, supporting both standard Helm repositories (HTTP/HTTPS) and OCI registries (using the oci:// protocol).

Workload Profile Revisions

Every time you create or edit a Workload Profile, PaletteAI automatically saves a revision, or snapshot, of that version as a DefinitionRevision resource. This lets you 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.

Clone a Workload Profile Version

You can clone a specific version or revision of a Workload Profile from the Workload Profile view page. This creates a copy of any version, not only the latest, so you can fork configurations or revert to a previous state.

To clone a specific version or revision:

1. Navigate to the Workload Profile view page.

2. Select the version or revision you want to clone using the version selector.

3. Select the Settings menu.

4. Select Clone Version (for semantic versioning) or Clone Revision (for sequential versioning).

   The cloned Workload Profile uses the selected version or revision as its starting point. You must have create permissions for Workload Profiles to perform this action.

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 report deployment status. Their specification includes a Workload Profile reference, a target Workload specification (name, namespace, and optional metadata), an Environment that determines replication and scheduling, and optional variables for templating.

PaletteAI renders the Definitions in a Workload specification into Kubernetes resources and applies them to one or more clusters in a multi-cluster environment. The selected Environment and its inputs determine which clusters receive the deployment.

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 declared variables.

Variables

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

For more information about how variables work and how PaletteAI resolves them, refer to Variables. To learn how to create and manage them, refer to Create and Manage Variables.

PaletteAI uses variables from four configuration sources:

1. Variables declared in an inline ProfileBundle.spec.variableSet.

2. Variables defined in WorkloadDeployment.spec.variables.

3. Variables defined in the Project VariableSet named mural-variables.

4. Variables defined in the mural-variables VariableSet in the system definition namespace (typically mural-system).

When you deploy from a Profile Bundle, PaletteAI uses inline ProfileBundle.spec.variableSet entries to declare bundle-specific defaults and metadata. In supported bundle workflows, PaletteAI carries those values into WorkloadDeployment.spec.variables before render.

Render-time precedence is:

1. WorkloadDeployment.spec.variables, including values carried forward from an inline ProfileBundle.spec.variableSet

2. The Project VariableSet

3. The system VariableSet

   The following lock behavior applies across all four sources.

   info

   If a variable is marked as locked in a VariableSet, Workload Deployment variables cannot override it. This is useful when you need to enforce organization-wide settings.

Workload Deployment overrides are limited to variables already declared in the effective VariableSet for the namespace or in the inline Profile Bundle variable set.

Workload Deployment Versions

By default, Workload Deployments are automatically updated whenever the underlying content of their Workload Profile or Environment is updated. You can 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.