Show HN: Holos – Configure Kubernetes with CUE data structures instead of YAML (opens in new tab)

Is gcl great? No. Cue and dhal have better semantics. Do some people abuse it? Sure, but still much better than helm templating.

CUE is a close cousin to Go, the authors are deeply involved in Go. Marcel worked with Rob Pike on the design of CUE. I could see how it’d feel foreign, without first appreciating Go maybe CUE wouldn’t have clicked for me.

In both cases it's tedious to manage the helm values, and they're usually managed without strong type checking or having been integrated into your platform as a whole. For example, you might pass a domain name to one chart and another value derived from the domain name to another chart, but the two charts likely use different field names for the inputs so the values are often inconsistent.

Holos uses CUE to unify the configuration into one holistic data structure, so we're able to look up data from well defined structures and pass them into Helm. We have an example of how this helps integrate the prometheus charts together at: https://holos.run/docs/v1alpha5/tutorial/helm-values/

This unification of configuration into one data structure isn't limited to Helm, you can produce resources for Kustomize from CUE in the same way, something that's otherwise quite difficult because Kustomize doesn't support templating. You can also mix-in resources to your existing Helm charts from CUE without needing to template yaml.

This approach works equally well for both in-house Helm charts you may have created to deploy your own software, or third party charts you're using to deploy off the shelf software.

We take a slightly different approach in a few important ways.

1. Holos stops short of applying manifests to a cluster, leaving that responsibility to existing tools like ArgoCD, Flux, plain kubectl apply, or other tools. We're intentional about leaving space for other tools to operate after manifests are rendered before they're applied. For example, we pair nicely with Kargo for progressive rollouts. Kargo sits between Holos and the Kubernetes API and fits well with Holos because both tools are focused on the rendered manifest pattern.

2. Holos focus on the integration of multiple Components into an overall Platform. I capitalized them because they mean specific things in Holos, a Component is our way of wrapping existing Helm charts, Kustomize bases, and plain raw yaml files, in CUE to implement the rendering pipeline.

3. We're explicit about the rendering pipeline, our intent is that any tool that generates k8s config manifests could be wrapped up in a Generator in our pipeline. The output of that tool can then be fed into existing transformers like Kustomize.

I built the rendering pipeline this way because I often would take an upstream helm chart, mix in some ExternalSecret resources or what not, then pipe the output through Kustomize to tweak some things here and there. Holos is a generalization of that, it's been useful because I no longer need to write any YAML to work with Kustomize, it's all pure data in CUE to do the same thing.

Those are the major difference. I'd summarize them as holos focuses on the integration layer, integrating multiple things together. Kind of like an umbrella chart, but using well defined CUE as the method of integrating things together. The output of each tool is another main difference. Holos outputs fully rendered manifests to the local file system intended to be committed to a GitOps repo. Timoni acts as a controller, applying manifests to the cluster.

You also want to worry about all of the above as little as possible, which is why an abstraction like holos could be useful. I've been hoping to see an ergonomic application of CUE to k8s manifests for a while now.

Holos is designed to produce configuration for Kubernetes. That configuration can be as small as a 10 line yaml file, but in larger operations it often ends up being multiple millions of lines of yaml spread over multiple clusters across the globe.

Once Holos produces the configuration, we stop. We leave it up to you to decide what to do next with it. For example we pass it to ArgoCD to deploy, others pass it to Flux. In development I pass it directly to kubectl apply.

I also use helm for some software, but I never edit it, just configure using values.

Honestly it all seems like craziness and the day kustomize will not be enough for me, I'll just write small JavaScript program generating JSONs. Don't need to make it harder than that...

This allows one to easily stitch together both k8s as with all your other infra.

* k8s yaml in the repo, kubectl

* kustomize

* tanka and jsonnet

* pulumi

So far jsonnet is the only method that I've used successfully for a long time. I'm working on some new stuff with pulumi, though.