939de0cdbe
This PR:
* provides a code generator that converts
kustomize Go plugins to normal code, i.e.
the plugin appears as
t := builtin.NewImageTagTransformer()
instead of
p := plugin.Open("imagetagtransformer.so")
s := p.Lookup(someSymbol)
t, ok = s.(Transformer)
* converts the main processing thread in
kusttarget.go to use those factory calls to run
builtin generators and transformer before
calling user-supplied plugins,
* as an example, provides an imagetag transformer
plugin, converting a legacy transformer to
builtin plugin form with its own isolated test.
This test can be expanded by moving more code
into it, but that can be done in a later PR.
Writing core functionality as plugins assures a
maintained plugin authoring and testing framework,
assures modularity, provides meaningful plugin
examples, and gives us a means to make informed
choices on which kustomize packages to publish
(and which to move to internal/). The code
generator allows all this without losing "go get
sigs.k8s.io/kustomize" functionality.
TODO:
1) Convert remaining legacy transformers to
plugins (patch SMP/JSON, name prefix/suffix,
labels/annos) with their own tests. The
generators are already done; this PR wires
them up, and all tests & examples pass.
2) Push code down into the plugins, as the first
pass at conversion writes plugins as thin
layers over calls into code under the mess
that is pkg/. Once this is done, we can
reasonably move all the packages that aren't
imported by plugins to internal/.
This PR could be split in two, one to merge the
the generator, and the second to merge the
ImageTagTransformer plugin and its wiring into the
main flow.
The latter PR could then serve as an example for
converting the remaining transformers.
kustomize
kustomize lets you customize raw, template-free YAML
files for multiple purposes, leaving the original YAML
untouched and usable as is.
kustomize targets kubernetes; it understands and can
patch kubernetes style API objects. It's like
make, in that what it does is declared in a file,
and it's like sed, in that it emits editted text.
This tool is sponsored by sig-cli (KEP), and inspired by DAM.
Download a binary from the release page, or see these instructions.
Browse the docs or jump right into the tested examples.
kustomize v2.0.3 is available in kubectl v1.14.
Usage
1) Make a kustomization file
In some directory containing your YAML resource files (deployments, services, configmaps, etc.), create a kustomization file.
This file should declare those resources, and any customization to apply to them, e.g. add a common label.
File structure:
~/someApp ├── deployment.yaml ├── kustomization.yaml └── service.yaml
The resources in this directory could be a fork of someone else's configuration. If so, you can easily rebase from the source material to capture improvements, because you don't modify the resources directly.
Generate customized YAML with:
kustomize build ~/someApp
The YAML can be directly applied to a cluster:
kustomize build ~/someApp | kubectl apply -f -
2) Create variants using overlays
Manage traditional variants of a configuration - like development, staging and production - using overlays that modify a common base.
File structure:
~/someApp ├── base │ ├── deployment.yaml │ ├── kustomization.yaml │ └── service.yaml └── overlays ├── development │ ├── cpu_count.yaml │ ├── kustomization.yaml │ └── replica_count.yaml └── production ├── cpu_count.yaml ├── kustomization.yaml └── replica_count.yaml
Take the work from step (1) above, move it into a
someApp subdirectory called base, then
place overlays in a sibling directory.
An overlay is just another kustomization, refering to the base, and referring to patches to apply to that base.
This arrangement makes it easy to manage your
configuration with git. The base could have files
from an upstream repository managed by someone else.
The overlays could be in a repository you own.
Arranging the repo clones as siblings on disk avoids
the need for git submodules (though that works fine, if
you are a submodule fan).
Generate YAML with
kustomize build ~/someApp/overlays/production
The YAML can be directly applied to a cluster:
kustomize build ~/someApp/overlays/production | kubectl apply -f -
Community
To file bugs please read this.
Before working on an implementation, please
- Read the eschewed feature list.
- File an issue describing how the new feature would behave and label it kind/feature.
Other communication channels
- Slack
- Mailing List
- General kubernetes community page
Code of conduct
Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.