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.
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.
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 them to the controller as part of the workload template creation process
Provide the location (Git or Helm repo)
If your artifacts are in a private repository, ensure you configure an agent so that the controller can monitor it for updates.
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.
If you selected "Upload files manually" and your package type is "Helm", select the Helm chart (packaged as a TGZ file) and upload it.
If you selected "Upload files manually" and your package type is "k8s YAML", select the yaml file and upload it.
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.
Users are also provided with a number of advanced options for Helm
If you selected "Pull files from repository" and your package type is "k8s YAML", select the yaml file and upload it.
On successful workload template creation, you can view the list of templates of all package types
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.
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
Since a workload template does not specify the target namespace or placement, you have to specify these here
Either select from (a) the list of existing namespaces OR (b) create a new namespace as part of the stage
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
Wavelength zone applications can be deployed only using the Workload Templates and GitOps Pipelines
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
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
Create New Workload Template from Catalog screen appears with a list of catalog
- 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.