Skip to content

Overview

The controller allows users to create and manage multiple types of workloads.

  1. Kubernetes YAML
  2. Helm Charts
  3. Workload Wizard

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

  1. Cloaked k8s Control Plane (no inbound access needed, no roles in every cluster)
  2. Multi Cluster Deployments
  3. No need for kubectl

YAML based Workload


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

  1. Cloaked k8s Control Plane (no inbound access needed, no roles in every cluster)
  2. Multi Cluster Deployments
  3. No need for a Helm Client
  4. No need to deploy and manage Tiller in every cluster or potentially every namespace.

Helm based Workload


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

  1. No knowledge of Kubernetes YAML or Helm needed
  2. Multi Cluster application deployments
  3. Intent based deployments

Workload Wizard

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 synthentic 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.