Modal Title
DevOps Tools / Kubernetes / Software Development

Deploy Stateful Workloads on Kubernetes with Ondat and FluxCD

GitOps provides a single source of truth for Kubernetes manifests, preventing configuration drift, allowing easy rollbacks and changes to production safely.
Nov 9th, 2022 8:51am by
Featued image for: Deploy Stateful Workloads on Kubernetes with Ondat and FluxCD
Image via Pixabay.

With the ever increasing growth in Kubernetes adoption, enterprises are increasingly adopting GitOps to deploy their workloads to Kubernetes. Deploying secure, cloud native stateful applications requires a high level of performance across hybrid and multi-cloud environments. Using the scalable, highly performant storage provided by Ondat in combination with FluxCD, you can shift left security and accelerate software development. Using Weave GitOps Trusted Delivery to deploy Ondat, platform teams can easily provide consistency and speed up the time it takes to deploy Kubernetes clusters.

GitOps allows users to use git as their single source of truth for their Kubernetes manifests, thus preventing configuration drift, allowing easy rollbacks in case of issues and empowering any engineer to make changes to production in a controlled, safe manner.

In this tutorial, I am going to use FluxCD to manage Kubernetes workloads, and will be focussing on how we achieve this using this toolset, but this approach would easily adapt to other solutions.

For more information regarding setting up FluxCD and its capabilities, which are many, feel free to take a look at the following links:

We follow a similar approach to repository structure as that suggested in the final link above, so all examples will be based around this.

FluxCD supports Helm deployments out of the box (https://fluxcd.io/flux/components/helm/). This is also the recommended approach for deploying Ondat, so we will be using this method.

Getting Started with Ondat

The first step is to sign up to Ondat and create a cluster object in the portal:

Once completed, you will obtain a Helm command to install Ondat on your cluster. This is what we will base the next step upon.

First, we create a namespace, as we like to keep the Helm objects in the same place as Ondat itself:


As part of our foundation directory, we define the following HelmRepository object:


As well as the following HelmRelease object:


The values section is where we can define any parameters we may need to changes as available in the values.yaml file belonging to the Helm chart. (https://github.com/ondat/charts/blob/main/charts/umbrella-charts/ondat/values.yaml)

Note that we have defined the value for ondat-operator.cluster.portalManager.secret as a reference to a Kubernetes secret in the example above. Kubernetes secrets are a vast topic in themselves, far too large for discussion in this blog post, but it is highly recommended to store this information in a secure manner.

You will need to copy the values for tenantID and clientID from the Helm command you see in your portal to ensure the portal manager is able to register itself correctly.

Also note that we have pinned the chart version, due to the nature of what Ondat does, upgrades should be performed carefully and thus we recommend pinning the version at this time.

Once this is applied, we can see the status of the HelmRelease using flux get all -n storageos.


We can also perform an additional check to ensure we’re ready to use Ondat by running kubectl get storageClass and checking there is now an entry for storageos.

Finally, we need to apply a license to the newly provisioned cluster by returning to the portal and selecting the license we desire. At this point we are ready to deploy our stateful workloads in a GitOps-controlled manner!

Join us for a live webinar on Nov. 16 at 8 a.m. PT/4 p.m. GMT on “Deploying Stateful Applications Securely and Confidently with Ondat and Weave GitOps.” Register here

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.