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 files manually" 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 files manually" and your package type is "k8s YAML", select the yaml file and upload it.

Upload Helm Chart

Repository¶

Helm Chart¶

If you selected "Pull files from repository" 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 "Pull files from repository" 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

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
Enter a Workload Custom Name

Project¶

Choose from either (a) the existing projects list or (b) specify a custom value using an expression.

When selecting existing projects, choose any project from the dropdown
If selecting a custom value, provide the expression for the value file path. An example of a custom value expression is {{ (split "/" (index .trigger.payload.head_commit.modified 0))._0 }} for the path "demo/value.yaml" specified in the workload template repository configuration

This selection allows users to deploy the workload template in a different project via a pipeline. To ensure the successful deployment of the workload template in other projects, it is mandatory to share the following information with the projects aiming to deploy the workload template:

Repository (utilized in the workload template)
Workload Template
Pipeline

Namespace¶

Select from either (a) the existing namespace list or (b) specify a custom value using an expression (similar to project). When deploying a workload template in another project via a pipeline, the target project should have the same namespace as the deployed workload.

Placement¶

Select placement type to determine the target clusters for deployment

Use Template in Stage

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)

Overrides¶

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

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