xtruder
Rejuventate with kustomize White Box Application concept
The k8s ecosystem is starting to catch up with it's deficiencies over nix.
https://kubectl.docs.kubernetes.io/guides/app_deployment/publishing_bases/
This means, it wold be tremendously useful if kubenix could hook into White Box Application concept, yet allow users to customize according to accustomed nix's powers.
Why? How? It looks like yet more kubernetes yaml madness. Does this look like kubenix consuming kustomization resources now too and converting them to Nix, or something else? Are there actually folks trying to use Nix... and the kustomize ecosystem? I have a hard time imagining that user.
Why? How? It looks like yet more kubernetes yaml madness.
I suspect there will be an emerging/converging White Box Application ecosystem. It would be useful for kubenix to capture this configuration database and enable users to employ the power of nix/nickel for overlays.
So the intention of this suggestion is:
- avoid yaml madness
- hook into a growing configuration database with great potential
Are there actually folks trying to use Nix... and the kustomize ecosystem?
I think we first need to acknowledge the myriad of potential impacts of kustomize now being merged fully into kubectl in terms of an emerging standard for off-the-shelf k8s configs.
I'm comparing kubenix + nix to kpt + kustomize.
quick notes to self (eventually expanding):
-
kpt→inputs.X.url = ...?/dir=path/to/deploydir -
kustomize→nix
It would be appropriate for kubenix to load kustomize projects out in the wild, render them with kustomize and make them available for modification with nix a la lib.revursiveUpdate (but with a little extra implementation of the k8s native merge strategies for associative arrays and arrays in general).
This repo has been deprecated, since I stopped maintaining it some time ago. There is a fork maintained by @hall available at https://github.com/hall/kubenix, that has better documentation and looks like a way further.
