You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
The text was updated successfully, but these errors were encountered: