Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation should contrast kustomize with other tools (helm, ksonnet, etc.) #53

Closed
wstrange opened this issue Jun 5, 2018 · 1 comment

Comments

@wstrange
Copy link

wstrange commented Jun 5, 2018

It is not clear when I would want to use kustomize vs. other tools such as helm or ksonnet.

What are the pros/cons of using kustomize?

Does kustomize interoperate with other tools?

@monopole
Copy link
Contributor

monopole commented Jun 6, 2018

That's more appropriate to a blog post or review.

The doc for tool x shouldn't have to track what
related tools do as time passes.

But since you asked :)

Does kustomize interoperate with other tools?

kustomize reads YAML, modifies it in memory per rules
found in kustomization.YAML files, and writes YAML to
stdout.

So it interoperates with anything that writes or reads
YAML. It can read helm or ksonnet output (to the extent
that one can get those tools to write YAML to a file
descriptor).

What are the pros/cons of using kustomize?

kustomize was inspired by this
doc, which offers a pro/con
discussion of different approaches to k8s configuration.

kustomize is meant avoid introducing a layer that wraps
the k8s API, yet still allow one to perform
common customizations to k8s objects.

kustomize is unobtrusive.

Say you have a directory myconfig containing files
with k8s resource YAML, and you can run this:

kubectl apply -f myconfig

You can drop a kustomization.yaml file into the
myconfig directory and still run the same command -
kubectl won't recognize the kustomization file.

But now you have the option of doing this too:

kustomize build myconfig | kubectl apply -f -

kustomize will apply the rules found in
kustomization.yaml to modify the API objects on their
way to the cluster. The kustomization file doesn't
have to sit in the same directory, but it makes
sense to keep it there in version control.

kustomize aspires to remain a single purpose unix tool
like sed or make that can be slotted in with other
tools.

If you're hired (or come oncall) to run a cluster
that's configured using kustomize, you don't need to
learn a new language/layer to understand the
configuration stored in version control. The config
remains k8s API objects, and it will evolve at the
same rate as the k8s API, warts and all.

Kustomize is appropriate for a gitops-style
workflow
, where there's a common base configuration that is
tweaked in various directions with overlays to create
different variants. The base and overlays can be
managed by separate teams in different repositories.
Kustomize facilitates merging this information via
mixin composition and patching.

@monopole monopole closed this as completed Jun 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants