[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: