Hacker News new | ask | show | jobs
by mkobit 2616 days ago
`kustomize` is an interesting and useful tool, and it is cool to see it available directly in `kubectl` in 1.14. A lower barrier to entry is nice to have for tools like this. It is useful on its own, but I'm also looking forward to additional features like being able to reuse a single patch on multiple targets (https://github.com/kubernetes-sigs/kustomize/issues/720). I'd also like to see a clear schema for what the YAML needs to look like and what the keys do. I wish it folowwed a similar pattern as `kubernetes` resources where each resource had an `apiVersion`, and the `kustomization` itself had an `apiVersion`.

Some newer documentation can be found at https://kubectl.docs.kubernetes.io/ which is still a little bit barren, but I expect it to improve. Some of the older documentation can be found at https://github.com/kubernetes-sigs/kustomize/tree/a5bb5479fb... (before the tool was integrated directly as a subcommand)
3 comments
jcastro 2616 days ago
Joe Beda (one of the k8s cofounders) just did a livestream on kustomize last week and I learned a bunch of stuff: https://www.youtube.com/watch?v=NFnpUlt0IuM

Full Disclosure: I work with Joe @ VMware

link
Benjamin_Dobell 2616 days ago
I just did the big 1.x -> 2.x refactor myself, and whilst it's not exactly pretty you can still reuse patches to some degree. It's just that every patch that will be applied independently now needs to be part of its own "base". You can then pull in the "base" wherever you want the patch applied. It's far from ideal, so I do hope the process improves, but it does at least work

EDIT: Although, after properly reading that linked issue, I see you mean applying the same patch to different resources. I interpreted "target" to mean build target (e.g. deployment/app), you can use the same patch across different deployments (apps) and overlays (environment). However, I see your use case is a bit different.

> I wish it folowwed a similar pattern as `kubernetes` resources where each resource had an `apiVersion`, and the `kustomization` itself had an `apiVersion`.

As of 2.0, this is now the case[1]:

> apiVersion: kustomize.config.k8s.io/v1beta1

> kind: Kustomization

[1] https://github.com/kubernetes-sigs/kustomize/blob/a5bb5479fb...

link
dilyevsky 2616 days ago
Honestly it would probably make more sense to have it versioned by git tag/branch (a la terraform modules) for straight forward gitops integration.
link