Hacker News Reader

Comment by andix | Hacker News Reader

I don't think that the k8s yamls/jsons are bad. It's just bad that we write and edit them as text files

My take on the k8s yaml mess is, that we are lacking a modern replacement for Helm. The yaml templating on text file level is just pure crazyness. I think we would need an approach that is more like React/JSX or even better TSX (typescript JSX). Some possibility to get away from simple templating and more into structured descriptions, with typing and control flows.

I think there are some approaches into this direction (like the k8s Terraform module, or the defunct ksonnet), but none of them got it perfectly right yet.

View on HN

This is a naive thought, as someone who has only been doing devops stuff for a little over a year...but what about HCL? Terraform was my favorite aspect of the devops stack, because I really enjoyed the simplicity of the configuration language. It just made sense to me.

There is a kubernetes provider for terraform: https://registry.terraform.io/providers/hashicorp/kubernetes...

I just think it doesn't map well to the declarative way of kubernetes. And HCL/Terraform often feel a bit clumsy when control flow/complex mapping is needed. Doesn't feel like a real programming language.

Terraform is great for managing cloud resources, diffing and applying changes. But this is not needed for kubernetes, in some way k8s can even be considered an alternative terraform (declare desired resources, k8s will create/update/destroy them as specified).

RCL has control flow and types: https://rcl-lang.org/. No record types yet though, so they are not yet very useful to validate e.g. a Kubernetes manifest against a schema.

Looks a lot like Jsonnet. This is going into the direction I'm talking about.

Is there also some typing-checking/code-completion available for Kubernetes resources? I think this would be an essential part to improve developer experience and automatic checks.

Some linter to validate the k8s manifests must be a part of a solution. It's possible to check the output, but a perfect solution would also lint the RCL source code and highlight the sections that generate invalid manifests.

At the moment nothing like that exists. Eventually it should be possible to generate RCL types like https://github.com/dhall-lang/dhall-kubernetes does for Dhall.

I was just comparing different approaches and stumbled upon KCL. Might be worth a look:

https://www.kcl-lang.io/docs/user_docs/getting-started/intro

Reply on news.ycombinator.com