Advent Calendar Day 2: Converting Kasten Helm Commands

Advent Calendar Day 2: Converting Kasten Helm Commands to Repeatable YAML

Disclaimer:
I’m not a professional developer, and this script was created on a beta build of the software. It is intended to demonstrate the “art of the possible” rather than serve as production-ready code. Use this example with caution, and test thoroughly in your environment before relying on it for critical tasks.

Welcome back to Day 2 of our Veeam Blog Advent Calendar! Yesterday we kicked things off with an introduction to the series, and today we’re diving straight into our first topic: Automation.

If you’ve been following my Kubernetes 101 series, you’ll remember we installed Kasten K10 using a pretty straightforward Helm command. While that works perfectly fine for getting up and running, it’s not exactly what I’d call “repeatable” or “version-controlled friendly.” Every time you want to deploy Kasten with the same configuration, you’re either copying and pasting from documentation or trying to remember what flags you used last time.

There’s got to be a better way, right? Well, there is! Today I’m going to show you how to convert those long Helm install commands into a clean, reusable YAML file that you can commit to Git, share with your team, and deploy consistently every single time.

The Problem with Long Helm Commands

Let’s be honest, nobody likes typing out (or worse, copying and pasting) commands like this:

helm install k10 kasten/k10 --namespace=kasten-io \
    --set externalGateway.create=true \
    --set auth.tokenAuth.enabled=true \
    --set prometheus.server.enabled=false \
    --set grafana.enabled=false

And that’s a simple example! In production environments, you might have dozens of --set flags for things like:

  • Ingress configurations
  • Resource limits and requests
  • Custom storage classes
  • Authentication settings
  • Feature flags
  • And much more…

The real issues with this approach are:

  1. It’s error-prone: One typo and your deployment might not work as expected
  2. It’s not version-controlled: How do you track what changed between deployments?
  3. It’s not reusable: Want to deploy to another cluster? Time to copy-paste again
  4. It’s hard to review: Try spotting the difference between two long commands

Enter the Kasten Install Generator

Kasten provides an awesome tool at install.kasten.io that generates the Helm install command based on your selections. It’s a great starting point, but it still gives you that long command string we want to avoid.

Here’s where we get clever. Instead of just copying that command, we’re going to write a script that converts it into a proper kasten-values.yml file that we can use with Helm.

The Solution: A Custom Shell Script

I’ve created a simple shell script that takes the output from the Kasten install generator and converts it into a clean YAML file. The script uses a combination of bash and Python to reliably parse and structure the YAML output.

Note: This script requires Python 3, which is pre-installed on macOS and most Linux distributions. If you’re on Windows, you can run this in WSL or Git Bash with Python installed.

How to Use It

The workflow is dead simple:

  1. Visit the Kasten Install Generator: Head over to install.kasten.io and configure your installation with all the options you need

  2. Copy the Generated Command: Once you’ve selected all your options, copy the Helm install command it generates

  3. Run the Script:

    git clone https://gitlab.com/veeam_scripts/helm-to-yaml.git
    chmod +x helm-to-yaml.sh
    ./helm-to-yaml.sh
    
  4. Paste and Convert: Paste your Helm command, press Ctrl+D, and watch the magic happen!

The script will create a kasten-values.yml file that looks something like this:

# Kasten K10 Values File
# Generated on Mon Dec  2 09:00:00 AEDT 2025
# Use with: helm install k10 kasten/k10 --namespace=kasten-io -f kasten-values.yml

datastore:
  cacheSizeLimitMB: 0
externalGateway:
  create: true
auth:
  tokenAuth:
    enabled: true
prometheus:
  server:
    enabled: false
grafana:
  enabled: false

Much cleaner, right?

Real-World Example

Let’s say you generated this command from install.kasten.io:

helm install k10 kasten/k10 \
--namespace 'kasten-io' \
--create-namespace \
--set "externalGateway.create=true" \
--set "auth.tokenAuth.enabled=true" \
--set "datastore.cacheSizeLimitMB=0"

After running it through our script, you get:

# Kasten K10 Values File  
# Generated on Mon Dec  2 09:00:00 AEDT 2025
# Use with: helm install k10 kasten/k10 --namespace=kasten-io -f kasten-values.yml

auth:
  tokenAuth:
    enabled: true
datastore:
  cacheSizeLimitMB: 0
externalGateway:
  create: true

Now you can install Kasten with a simple, clean command:

helm install k10 kasten/k10 --namespace=kasten-io -f kasten-values.yml

Why This Matters

Now that you have a proper YAML file, you can:

Version Control It

Commit this file to your Git repository alongside your other infrastructure code. Now you have a complete history of what changed and when:

git add kasten-values.yml
git commit -m "Update Kasten configuration to enable external gateway"
git push

Review Changes Easily

Want to see what changed between deployments? Just use Git diff:

git diff kasten-values.yml

This is infinitely easier than comparing two long Helm commands!

Reuse Across Environments

Need to deploy Kasten to dev, test, and prod? Create environment-specific values files:

kasten-values-dev.yml
kasten-values-test.yml
kasten-values-prod.yml

Then deploy with:

helm install k10 kasten/k10 --namespace=kasten-io -f kasten-values-prod.yml

Document Your Decisions

The YAML format is much more readable than a long command. You can even add comments to explain why certain values are set:

externalGateway:
  create: true  # Required for external access via MetalLB
auth:
  tokenAuth:
    enabled: true  # Using token auth instead of basic auth for better security

Wrapping Up

This might seem like a small thing, converting a command to a YAML file but it’s these small automation wins that add up to a more professional, maintainable infrastructure. When you’re managing multiple clusters or working in a team, having clean, version-controlled configuration files isn’t just nice to have, it’s essential.

Plus, once you’ve done this for Kasten, you can apply the same approach to any other Helm charts you’re deploying. The pattern is universal, and the benefits compound over time. There you have it, Day 2 of our Advent Calendar and our first automation win! We’ve taken a long, unwieldy Helm command and transformed it into a clean, reusable YAML file that can be version-controlled, reviewed, and deployed consistently across environments.

Tomorrow we’ll continue our automation journey with another practical tip. Until then, why not take this script for a spin and start converting those Helm commands into proper values files? Your future self will thank you!

Quick Reference

Script Location: I’ve added the helm-to-yaml.sh script to my Gitlab

See you tomorrow for Day 3! 🎄