Overview
The controller allows users to create and manage multiple types of workloads.
- Kubernetes YAML
- Helm Charts
- Workload Wizard
The below matrix presents a breakdown of actions like creation, updating, deletion, publish/unpublish Kubernetes Namespaces across multiple deployment methods: Interactive UI, Declarative RCTL commands, API-driven automation, and Terraform.
| Workload Type | Deployment Method | Create | Edit/Update | Delete | Publish | Unpublish |
|---|---|---|---|---|---|---|
| Helm3 | UI | Yes | Yes | Yes | Yes | Yes |
| CLI | Yes | Yes | Yes | Yes | Yes | |
| API Automation | Yes | Yes | Yes | Yes | Yes | |
| Terraform | Yes | Yes | Yes | Yes | Yes | |
| K8s YAML | UI | Yes | Yes | Yes | Yes | Yes |
| CLI | Yes | Yes | Yes | Yes | Yes | |
| API Automation | Yes | Yes | Yes | Yes | Yes | |
| Terraform | Yes | Yes | Yes | Yes | Yes | |
| Workload Wizard | UI | Yes | Yes | Yes | Yes | Yes |
| CLI | Yes | Yes | Yes | Yes | Yes | |
| API Automation | Yes | Yes | Yes | Yes | Yes | |
| Terraform | Yes | Yes | Yes | Yes | Yes |
Kubernetes YAML¶
This option is ideal for situations where the user already has the Kubernetes YAML for their application.
During workload deployment, the controller will validate the provided yaml file and deploy it to multiple managed Kubernetes clusters (as per configured policy).
Benefits¶
- Cloaked K8s Control Plane (no inbound access needed, no roles in every cluster)
- Multi Cluster Deployments
- No need for kubectl
Helm Charts¶
This option is well suited for 3rd party applications that are packaged and distributed as Helm charts. It is also a good option for users that have invested in packaging their application as Helm charts.
During workload deployment, the controller will validate the provided Helm chart (a tgz file) and deploy it to multiple managed Kubernetes clusters (as per configured policy)
Benefits¶
- Cloaked K8s Control Plane (no inbound access needed, no roles in every cluster)
- Multi Cluster Deployments
- No need for a Helm Client
- No need to deploy and manage Tiller in every cluster or potentially every namespace.
Workload Wizard¶
This option is ideal for users that are not familiar with Kubernetes YAML or Helm charts.
The workload wizard based guided workflow allows users to intuitively specify application intent in seconds. The wizard then automatically "translates" the specified intent and generates the necessary Kubernetes YAML during workload deployment.
Benefits¶
- No knowledge of Kubernetes YAML or Helm needed
- Multi Cluster application deployments
- Intent based deployments
No Ingress Workloads¶
Containerized applications of this type do not need to support inbound requests by users or systems.
A common use case for applications of this type are synthetic testing tools that application teams may use for performance and/or availability testing their applications from various regions.
For example, a large B2C web application serving a global user base may wish to run their "user simulation" test tool periodically from every location where they have a critical set of users.
The application team can use this to perform early detection of regional user access issues (NW congestion etc) so that they can attempt to resolve them before customers start complaining.
Alternatively, application teams can embed this into their CI/CD pipelines making this part of their application upgrade workflows. This way, they can guarantee that the application has not regressed in any non-obvious way from the previous version.
Workloads with Ingress¶
This is the more frequent type of application where it accepts inbound requests from users and systems that interact with it.
Workload from Catalog¶
User are allowed to browse through apps in a catalog and create a workload from an app. User can either edit the values.yaml on controller or upload a values.yaml before publishing the app.
Below is an example of creating an Add-On from catalog
- Click New Workload drop-down and select Create New Workload from Catalog
Create New Workload from Catalog screen appears with a list of catalog
- Select the required catalog and proceed to create a workload
Refer Catalog for more information
- On successful creation, add-ons are listed with the type Catalog App as shown below
Explore our blog for deeper insights on How to Deploy a Vector Database on Kubernetes, available here!
GitOps Workloads¶
Click the GitOps Workloads tab to view the list of workloads created through System Sync (Git Sync) or RCTL using -v3 flag. Workloads and its corresponding namespace and placement details are available for the users.
By default, two (2) custom labels are shown. To view more, click View All (n)
