mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-05-21 14:32:03 +00:00
86 lines
3.0 KiB
Markdown
86 lines
3.0 KiB
Markdown
# Eschewed Features
|
|
|
|
For a bigger picture about why kustomize
|
|
does some things and not others, see the
|
|
glossary entry for [DAM].
|
|
|
|
## Removal directives
|
|
|
|
`kustomize` supports configurations that can be reasoned about as
|
|
_compositions_ or _mixins_ - concepts that are widely accepted as
|
|
a best practice in various programming languages.
|
|
|
|
To this end, `kustomize` offers various _addition_ directives. One
|
|
can add labels, annotations, patches, resources and bases.
|
|
Corresponding _removal_ directives are not offered.
|
|
|
|
Removal semantics would introduce many possibilities for
|
|
inconsistency, and the need to add code to detect, report and
|
|
reject it. It would also allow, and possibly encourage,
|
|
unnecessarily complex configuration layouts.
|
|
|
|
When faced with a situation where removal is desirable, it's
|
|
always possible to remove things from a base like labels and
|
|
annotations, and/or split multi-resource manifests into individual
|
|
resource files - then add things back as desired via the
|
|
[kustomization].
|
|
|
|
If the underlying base is outside of one's control, an [OTS
|
|
workflow] is the recommended best practice. Fork the base, remove
|
|
what you don't want and commit it to your private fork, then use
|
|
kustomize on your fork. As often as desired, use _git rebase_ to
|
|
capture improvements from the upstream base.
|
|
|
|
## Build-time side effects from CLI args or env variables
|
|
|
|
`kustomize` supports the best practice of storing one's
|
|
entire configuration in a version control system.
|
|
|
|
Changing `kustomize build` configuration output as a result
|
|
of additional arguments or flags to `build`, or by
|
|
consulting shell environment variable values in `build`
|
|
code, would violate that goal.
|
|
|
|
`kustomize` insteads offers [kustomization] file `edit`
|
|
commands. Like any shell command, they can accept
|
|
environment variable arguments.
|
|
|
|
For example, to set the tag used on an image to match an
|
|
environment variable, run
|
|
|
|
```
|
|
kustomize edit set imagetag nginx:$MY_NGINX_VERSION
|
|
```
|
|
|
|
as part of some encapsulating work flow executed before
|
|
`kustomize build`.
|
|
|
|
|
|
## Globs in kustomization files
|
|
|
|
`kustomize` supports the best practice of storing one's
|
|
entire configuration in a version control system.
|
|
|
|
Globbing the local file system for files not explicitly
|
|
declared in the [kustomization] file at `kustomize build` time
|
|
would violate that goal.
|
|
|
|
Allowing globbing in a kustomization file would also introduce
|
|
the same problems as allowing globbing in [java import]
|
|
declarations or BUILD/Makefile dependency rules.
|
|
|
|
`kustomize` will instead provide kustomization file editting
|
|
commands that accept globbed arguments, expand them at _edit
|
|
time_ relative to the local file system, and store the resulting
|
|
explicit names into the kustomization file.
|
|
|
|
In this way the resources, patches and bases used at _build time_
|
|
remain explicitly declared in version control.
|
|
|
|
|
|
[DAM]: glossary.md#declarative-application-management
|
|
[base]: glossary.md#base
|
|
[kustomization]: glossary.md#kustomization
|
|
[OTS workflow]: workflows.md#off-the-shelf-configuration
|
|
[java import]: https://www.codebyamir.com/blog/pitfalls-java-import-wildcards
|