kubernetes (next steps) - helm chart(s)

[mmguero]

Sub issue of #149

See the latest comment at the bottom of this issue for a more recent update on its status.

So far with Kubernetes we've just been writing the manifest files directly. Need to look into what would helm charts look like and how it would fit in with the deployment scripts, if at all (see #172)

[mmguero]

There's some discussion internally as to what this is actually going to buy us, beyond what we've already done with the Kubernetes manifests and our cross-platform configuration and runtime scripts that configure the environment variable files used by both the docker-compose and Kubernetes deployment models.

From what I understand, the Helm charts are a way to generate the kubernetes manifests (which we have already) from templates, replacing configuration values in the templates. What benefit is that beyond what we have right now with the environment variable files and the scripts that use the official kubernetes python API to do the actual deployment for you?

I'm not against the idea in principle, I do want to understand. But at the moment I'm wondering what's the motivation.

If we do decide that we need to do helm charts, here are some thoughts:

1. probably move the stuff in the ./kubernetes directory that's there now into like ./kubernetes/manifests then create a ./kubernetes/helm directory for the new helm chart stuff
2. I'd really like them to use the existing environment variable file structure if possible, less complication if everything is doing the same thing
3. Can the helm charts create the configmaps not only from the environment variable files but also from local files/directories like we're doing for Kubernetes already?

[mmguero]

A partner organization has been contributing to our new idaholab/Malcolm-Helm repo for some time now. They've done a ton of the work for scaling out Malcolm and making a nice Helm chart.

From what I can tell, most of what they've done is pretty general-purpose, but we need to take this to the finish line and figure out a few things still. So, tasks that still exist for this issue include:

• Investigate idaholab/Malcolm-Helm from the standpoint of asking the question "what, if anything, do we need to adjust to make this suitable for use by the general public?"
• Test it in a variety of deployments (on-prem K3s, AWS, Azure?, etc.)
• identify which environment variables (see also the .env files for the compose deployment) and see which, if any need to be reflected in the values.yaml file
• whether or not the control scripts are used for starting/stopping/running, I'd like the configuration script to also be able to generate the values.yaml file, or maybe generate the .env files as an intermediary like it's doing today and then generate the values.yaml from there. That could even be a different script (idk, env2values.py or something) that takes as input a Malcolm config directory containing .env files and populates the values.yaml from there.
• once we're ready, update all kubernetes documentation (kubernetes-*.md from the source) to reflect using the helm chart as the preferred method of Kubernetes deployment

[mmguero]

going to assign this to @scott-jeffery once I get him added to the org