Haven't tried this out but, from the write up, I don't see what the convenience of this is over just using git + {kubectl, kustomize, helm}.
The Kubernetes ecosystem is rife with tools like this, and it feels like such a chore to just keep up with every new templating system for YAML files. I have started to just write Go programs that directly talk to the Kubernetes API and manage my rollouts (one step away from operators).
One key distinction is that this is not yet another templating DSL like Jinja, or Go templates that present an anti-pattern for non-trivial deployments. As an example, take a look at the Grafana Helm chart:
Kpt is an OSS tool for Kubernetes packaging. It uses a standard format to bundle, publish, customize, update, and apply configuration manifests. Kpt operates like kubectl, providing additional functionality to prune and delete configuration.
Single-purpose accounts aren't allowed on HN, nor are bots (if that's what this is). Also, it's not good to post summaries routinely. We want HN users to actually read articles. The less work readers do, the shallower and more predictable the comments tend to get.
I've banned this account, but if you want to use it to participate in the community as a regular member, you're welcome to email hn@ycombinator.com and let us know.
Haven't tried this out but, from the write up, I don't see what the convenience of this is over just using git + {kubectl, kustomize, helm}.
The Kubernetes ecosystem is rife with tools like this, and it feels like such a chore to just keep up with every new templating system for YAML files. I have started to just write Go programs that directly talk to the Kubernetes API and manage my rollouts (one step away from operators).
One key distinction is that this is not yet another templating DSL like Jinja, or Go templates that present an anti-pattern for non-trivial deployments. As an example, take a look at the Grafana Helm chart:
https://github.com/bitnami/charts/blob/master/bitnami/grafan...
It's more curly brackets than YAML :)
Instead, kpt's key design philosophy is to keep configuration as data. This makes it easier to develop tooling that operate on configs.
I don't understand why I would use this over Helm? I am even further confused when I go to the docs and it has guides for creating a kpt package from a helm chart: https://googlecontainertools.github.io/kpt/guides/ecosystem/
If you are going to introduce a new tool into an already crowded ecosystem the least you can do is describe why anyone should use it.
Summary:
Kpt is an OSS tool for Kubernetes packaging. It uses a standard format to bundle, publish, customize, update, and apply configuration manifests. Kpt operates like kubectl, providing additional functionality to prune and delete configuration.
Single-purpose accounts aren't allowed on HN, nor are bots (if that's what this is). Also, it's not good to post summaries routinely. We want HN users to actually read articles. The less work readers do, the shallower and more predictable the comments tend to get.
I've banned this account, but if you want to use it to participate in the community as a regular member, you're welcome to email hn@ycombinator.com and let us know.