Bug#1026018: ITP: kustomize -- Customization of kubernetes YAML configurations
Package: wnpp
Severity: wishlist
Owner: sun min <sunmin89@outlook.com>
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-go@lists.debian.org
* Package name : kustomize
Version : 3.3.1-1
Upstream Author : Kubernetes SIGs
* URL : https://github.com/kubernetes-sigs/kustomize
* License : Apache-2.0
Programming Lang: Go
Description : Customization of kubernetes YAML configurations
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
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#kubernetes-
style-object) API objects. It's like make
(https://www.gnu.org/software/make), in that what it does is declared in
a file, and it's like sed (https://www.gnu.org/software/sed), in that it
emits edited text.
.
This tool is sponsored by sig-cli
(https://github.com/kubernetes/community/blob/master/sig-cli/README.md)
(KEP (https://github.com/kubernetes/enhancements/blob/master/keps/sig-
cli/2377-Kustomize/README.md)).
.
* Installation instructions
(https://kubectl.docs.kubernetes.io/installation/kustomize/)
* General documentation
(https://kubectl.docs.kubernetes.io/references/kustomize/)
* Examples (/examples)
.
Build Status (https://prow.k8s.io/job-history/kubernetes-jenkins/pr-
logs/directory/kustomize-presubmit-master) Go Report Card
(https://goreportcard.com/report/github.com/kubernetes-sigs/kustomize)
.
kubectl integration
.
The kustomize build flow at v2.0.3 (https://github.com/kubernetes-
sigs/kustomize/releases/tag/v2.0.3) was added to kubectl v1.14
(https://kubernetes.io/blog/2019/03/25/kubernetes-1-14-release-
announcement). The kustomize flow in kubectl remained frozen at v2.0.3
until kubectl v1.21, which updated it to v4.0.5
(https://github.com/kubernetes/kubernetes/blob/4d75a6238a6e330337526e0513e67d02b1940b63/CHANGELOG/CHANGELOG-
1.21.md#kustomize-updates-in-kubectl). It will be updated on a regular
basis going forward, and such updates will be reflected in the
Kubernetes release notes.
.
KUBECTL VERSION | KUSTOMIZE VERSION
------------------+--------------------
< v1.14 | n/a
v1.14-v1.20 | v2.0.3
v1.21 | v4.0.5
v1.22 | v4.2.0
.
For examples and guides for using the kubectl integration please see the
kubernetes documentation (https://kubernetes.io/docs/tasks/manage-
kubernetes-objects/kustomization/).
.
Usage
.
1) Make a kustomization
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#kustomization)
file
.
In some directory containing your YAML resource
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#resource)
files (deployments, services, configmaps, etc.), create a kustomization
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#kustomization)
file.
.
This file should declare those resources, and any customization to apply
to them, e.g. *add a commonlabel*.
.
[Image: base image] (/images/base.jpg)
.
File structure:
.
|
.
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
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#apply)
to a cluster:
.
|
.
2) Create variants
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#variant)
using overlays
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#overlay)
.
Manage traditional variants
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#variant)
of a configuration - like *development*, *staging* and *production* -
using overlays
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#overlay)
that modify a common base
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#base).
.
[Image: overlay image] (/images/overlay.jpg)
.
File structure:
.
|
.
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, referring 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
(https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#apply)
to a cluster:
.
|
.
Community
.
* file a bug
(https://kubectl.docs.kubernetes.io/contributing/kustomize/bugs/)
* contribute a feature
(https://kubectl.docs.kubernetes.io/contributing/kustomize/features/)
* propose a larger enhancement (https://github.com/kubernetes-
sigs/kustomize/tree/master/proposals)
.
Code of conduct
.
Participation in the Kubernetes community is governed by the Kubernetes
Code of Conduct (/code-of-conduct.md).
Reply to: