Package: wnpp Severity: wishlist Owner: sun min <sunmi...@outlook.com> X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@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).
