If you’ve used Kubernetes configuration tools like Helm, cdk8s, or pretty much any other, you probably expect to need to write and edit the configuration by hand. Or probably now you try to use AI, which has improved significantly since last year, but still can’t perform repeated modifications predictably and reliably.

But what if you thought about your configuration as having an API and a schema?

You would build and use tools. You can do that with ConfigHub, which manages configuration as data.

ConfigHub supports a mechanism called functions, which you can write with our SDK, that can be invoked on selected configurations.

Some simple examples:

  • Need to update an image tag? Invoke set-image-reference

  • Scale horizontally? set-replicas

  • Scale vertically? set-container-resources

  • Change an environment variable? set-env-var

  • Add a label? set-label

  • Set the security context to best-practice values? set-pod-defaults --security-context

I use mutations as an example because they present a greater contrast with “as code” approaches, where editing of templates, patches, and configuration generation code is not amenable to such tooling.

Functions and other tools built around the API can be single purpose or multi-purpose, but they do not need to be monolithic in the way that configuration generators do in “as code” approaches. The configuration data is the source of record, so tools can be composed together to construct the final configuration to deploy. This interoperability means that you do not need to reinvent the wheel when you need to modify some additional properties. Just perform additional modifications.

Functions can also be as specific or as generic as you like. A function like set-image-reference targets specific, built-in fields of specific resource types, which simplifies configuration changes, similar to a CLI, and can reduce the opportunity for errors. Other functions, such as set-string-path and yq-i can modify arbitrary fields, but you need to provide the paths to target.

Of course, validation, queries, and value extraction are also enabled by treating configuration as structured data with schemas. Want to know what image is running in each environment? get-image will extract that information for you.

Other APIs are more challenging to maintain in a serialized form, but the Kubernetes API was designed for this. Kubernetes resources, even many custom resources, and cloud resources have schemas that are stable and backward compatible.

Application configuration files may not have formal schemas, but such schemas can be defined. For example, I pointed an AI agent at Grafana’s LDAP configuration documentation and asked it to generate a schema, and it produced a 250-line schema in one shot. A schema specification is not strictly required, but is useful for validation.

The point is that configuration properties are well defined and can be targeted by tools, not just written out by hand over and over again.

As we can see from the rich ecosystem of tools built around Kubernetes, when we build around a common API, more and more useful tools are added to the toolbox over time — forward progress is made. On the other hand, if we keep building new parallel but incompatible ecosystems of configuration generation languages, whether templates, DSLs, or general-purpose languages, we’re reinventing the wheel over and over again. Not only that, but we’re limiting the kinds of tools that can be built around them to just a few kinds of tools due to the complicated syntax and unidirectional process:

  1. Syntax-aware IDEs.

  2. Scaffolding tools — templating templates! These are fire-and-forget configuration generation tools, generally.

  3. Tools that treat the configuration generation code as a black box, such as deployment tools and version-control systems.

  4. Tools that manipulate input variable values.

  5. Tools that operate on the rendered output, such as validation tools and patching tools.

  6. AI-based tools.

I have a background in compilers, but requiring compiler techniques or AI to build most kinds of tools drastically limits what can be built, who can build them, and when it makes sense to build them.

These kinds of tools are also largely anchored in human-driven processes. For example, validation tools find problems but cannot fix them, whereas automatic remediation is feasible with API-based tools.

I look forward to the tools will be developed once we’re not wrapping configuration data with obstructive layers of complexity.

Are there tools that work directly with the Kubernetes API that you wish you could apply to configuration files as well? Would you or members of your organization prefer to use a GUI rather than editing configuration files in git? Do you feel the toil of pushing changes through git to make small configuration changes? Have you ever needed to make similar changes to dozens of configuration files? What tools would you build to modify, inspect, analyze, or validate configuration if it were easier to do?

Feel free to email us at hello@confighub.com, or send me a message on LinkedIn, X/Twitter, or Bluesky.

You could also try out ConfigHub, which is now in preview.

If you found this interesting, you may be interested in other posts in my Infrastructure as Code and Declarative Configuration series or in my Kubernetes series.