Skip to content

Workload Template

A workload is restricted to a specific namespace and placement policy assigned to it. When a workload is used in multiple stages of a pipeline, there may be a need to use environment/stage specific overrides outside the workload definition. Workload templates do not have "namespace" and "placement" associated with it. Therefore, when a workload template is used in a stage in a pipeline, it is necessary to assign namespace and placement. These can be provided dynamically in a Stage in a pipeline.


Use Cases

Described below are some example use cases where workload templating can be extremely valuable

Developer Test Beds

Every developer in the team is provided their own "test bed". Every time there is a new version/build, the test beds for all developers need to be updated and made current automatically.

Hosted Software

ISV hosts a copy of the same workload in a "separate namespace per customer". ISV wants the software to be kept patched and updated automatically without having to manually handle the workloads one by one.


Create Workload Template

You can create a workload template imperatively using the Console or declaratively using a workload template spec YAML file and use it via the RCTL CLI.

  • Provide a unique name for the workload so that you can refer to it and find it later
  • Specify the package type (Both "Helm 3" or "YAML" formats are supported)
  • Specify how the artifacts can be accessed. You have two options

Upload Artifacts

Upload them to the controller as part of the workload template creation process

Create Workload Template

Repo Sync

Provide the location (Git or Helm repo)

Create Workload Template

Important

If your artifacts are in a private repository, ensure you configure an agent so that the controller can monitor it for updates.


Artifact Details

The artifacts associated with your workload template can either be a Helm chart or k8s YAML file. You can either provide it to the controller by uploading it or have the controller automatically retrieve it from your repository.

Upload Artifacts

Helm Chart

If you selected "upload artifacts" and your package type is "Helm", select the Helm chart (packaged as a TGZ file) and upload it.

Upload Helm Chart


k8s YAML

If you selected "upload artifacts" and your package type is "k8s YAML", select the yaml file and upload it.

Upload Helm Chart


Repository

Helm Chart

If you selected "upload artifacts" and your package type is "Helm", select the Helm chart (packaged as a TGZ file) and upload it.

Helm Chart-Repository

Users are also provided with a number of advanced options for Helm

Helm Chart-Repository - Advanced Options


k8s YAML

If you selected "upload artifacts" and your package type is "k8s YAML", select the yaml file and upload it.

k8s YAML-Repository

On successful workload template creation, you can view the list of templates of all package types

k8s YAML-Repository


Workload Templates Sharing

Use the Manage Sharing icon to share the workload templates to one or more projects (or) all projects. The templates created in a project can be edited or deleted within the same project. Templates inherited from other projects (shared by other projects) cannot be edited or deleted.

k8s YAML-Repository


Use Workload Template

Once created, workload templates can be used in a Stage in a Pipeline.

  • Provide a name for the stage
  • Select Workload Template from Actions
  • Select the workload template you need from the dropdown. This contains all the templates created within this project and inherited from other projects

Overrides

Since a workload template does not specify the target namespace or placement, you have to specify these here

Namespace

Either select from (a) the list of existing namespaces OR (b) create a new namespace as part of the stage

Placement

Select placement type to determine the target clusters for deployment

Advanced - Node Grouping Keys

Select one or more Node Group Keys to deploy on the target cluster

Placement of workload within multiple node groups in a cluster is supported now. A Node group is a logical collection of nodes based on a specified label key and this key is called nodeGroupingKey

For the nodes present in AWS wavelength zone, the key alpha.rafay.io/wl-zone is available in the system. Users can pick this key as nodeGroupingKey or any customized key to deploy in all wavelength zones in the cluster. Also, you can select multiple node grouping keys across the cluster but no node must appear in more than one node group

Important

Wavelength zone applications can be deployed only using the Workload Templates and GitOps Pipelines

Drift Action

Specify the kind of action you wish to take w.r.t. drift detection (Not Set, Detect and Notify and Detect and Block are possible options)

Revision from Webhook Trigger

By default, Use Revision from Webhook Trigger is set to False, where the commit revision from the trigger will not be used to deploy the workload. Set True to ensure the trigger's repo and workload template's repo are the same and the commit revision due to which the triggered pipeline is present in the workload template's repo

Use Template in Stage


Workload Template from Catalog

Catalog (System Catalog) is a collection of apps that a user can deploy to Kubernetes clusters as a workload template.

Below is an example of creating an Workload Template from catalog

  • Click the New Workload Template drop-down and select Create New Workload Template from Catalog

Provide Artifact

Create New Workload Template from Catalog screen appears with a list of catalog

Provide Artifact

  • Select the required catalog and proceed to create an workload template

Refer Catalog for more information

  • On successful creation, workload templates are listed with the type Catalog App as shown below.

View All addons