# Kustomize – Kustomize

https://kubernetes-sigs.github.io/kustomize/ Recent content on Kustomize Hugo -- gohugo.io

# Blog: v3.3.0

https://kubernetes-sigs.github.io/kustomize/blog/2019/10/24/v3.3.0/ Thu, 24 Oct 2019 00:00:00 +0000

https://kubernetes-sigs.github.io/kustomize/blog/2019/10/24/v3.3.0/

<h2 id="summary-of-changes">Summary of changes</h2> <h3 id="first-release-of-the-go-api-only-module">First release of the Go API-only module</h3> <p>Many of the PRs since the last vrelease were around restructuring the <em>sigs.k8s.io/kustomize</em> repository into three Go modules instead of just one.</p> <p>The reasons for this are detailed in the <a href="https://kubernetes-sigs.github.io/kustomize/site/content/en/faq/versioningPolicy.md">versioning policy documentation</a>, and what it means for releasing is explained in the <a href="https://kubernetes-sigs.github.io/kustomize/releasing">release process documentation</a>.</p> <p>The tl;dr is that the top level module <code>sigs.k8s.io/kustomize</code> now defines the kustomize Go API, and the <em>kustomize</em> CLI sits below it in an independent module <code>sigs.k8s.io/kustomize/kustomize</code>.</p> <p>The modules release independently, though in practice a new release of the kustomize Go API will likely be followed quickly by a new release of the <code>kustomize</code> executable.</p> <p>This is a necessary step to creating a much smaller kustomize Go API surface that has some hope of conforming to semantic versioning and being of some use to clients.</p> <p>The kustomize CLI will see the same kustomize Go API as any other client.</p> <p>The new semver-able API will begin with <code>v4.0.0</code> (not yet released) and be a clean break with <code>v3</code> etc.</p> <h3 id="change-log-since-v320">Change log since v3.2.0</h3> <pre><code>3c9d828f - Have kustomize CLI depend on kustomize Go API v3.3.0 (Jeffrey Regan) 5d800f0b - Merge pull request #1595 from monopole/threeReleases (Jeff Regan) 4eb2d5bc - Three builders. (Jeffrey Regan) 988af1ff - Update README.md (Jeff Regan) 1617183e - Merge pull request #1590 from monopole/releaseProcessUpdate (Kubernetes Prow Robot) ee727464 - update release process doc (jregan) c9e7dc3b - Merge pull request #1589 from monopole/moreTestsAroundKustFileName (Jeff Regan) 07e0e46a - improve tests for alternative kustomization file names (Jeffrey Regan) 404d2d63 - Merge pull request #1587 from monopole/reducePgmconfig (Jeff Regan) baa0296a - Reduce size of pgmconfig package (Jeffrey Regan) 0f665ac1 - Merge pull request #1544 from ptux/add-transformer-href (Jeff Regan) 14b0a650 - Merge pull request #1581 from monopole/refactorFs (Jeff Regan) 2d58f8b8 - Break the dep between fs and pgmconfig. (Jeffrey Regan) 9a43ca53 - Merge pull request #1578 from nlamirault/fix/build-plugins-doc (Jeff Regan) 5372fc6f - Merge pull request #1579 from monopole/fsPackageCleanup (Jeff Regan) 86bc3440 - Merge pull request #1513 from nimohunter/fix_empty_list_item (Kubernetes Prow Robot) a014f7d4 - Merge pull request #1561 from beautytiger/dev-190925 (Jeff Regan) 9a94bcb8 - Improve fs package and doc in prep to officially go public (Jeffrey Regan) 07634ef0 - Merge pull request #1575 from monopole/versioning (Jeff Regan) 995f88d6 - Update versioning notes. (jregan) 334a6467 - Fix: documentation link for plugins (Nicolas Lamirault) 08963ba5 - improve test code coverage in transformers (Guangming Wang) 326fb689 - Merge pull request #1570 from bzub/1234-go_plugin_doc (Jeff Regan) 970ce67c - Update goPluginCaveats.md (Jeff Regan) 98d18930 - Update INSTALL.md (Jeff Regan) d89b448c - Fix git tag recovery in cloud build. (Jeff Regan) 17bf9d32 - Update releasing README. (Jeff Regan) a99aff1d - Merge pull request #1571 from monopole/updateCloudBuildProcess (Kubernetes Prow Robot) a694ac7b - Update cloud build process for kustomize. (Jeffrey Regan) b5b11ef6 - Fix compile kustomize example. (bzub) fa1af6f5 - Merge pull request #1473 from richardmarshall/execpluginhash (Jeff Regan) 9288dec0 - Fix failing BashedConfigMapTest (Jeff Regan) 1a45dd0b - Merge pull request #1566 from monopole/releaseNotes3.2.1 (Kubernetes Prow Robot) 592c5acf - docs: Exec plugin generator options (Richard Marshall) ac9424fa - tests: Add unit tests for update resource options (Richard Marshall) 79fbe7c4 - Support resource generator options in exec plugins (Richard Marshall) f69d526f - v3.2.1 release notes (Jeff Regan) 07a95a60 - Merge pull request #1565 from monopole/tweakBinaryDepsBeforeTagging (Jeff Regan) 032b3857 - Pin the kustomize binary's dependence on kustomize libs. (jregan) 81062959 - Merge pull request #1564 from monopole/moveKustomizeBinaryToOwnModule (Kubernetes Prow Robot) b82a8fd3 - Move the kustomize binary to its own module. (Jeffrey Regan) 2d0c22d6 - Merge pull request #1562 from keleustes/tools (Kubernetes Prow Robot) aa342def - Pin tool versions using go modules (Ian Howell) 10786ec0 - Merge pull request #1554 from keleustes/readme (Kubernetes Prow Robot) 7c705687 - Update README.md to include Kubernetes 1.16 (Jerome Brette) e8933d97 - Merge pull request #1560 from monopole/precommitTuneup (Jeff Regan) 9d7b6544 - Make pre-commit more portable and less tricky. (jregan) 7a0946a9 - Merge pull request #1558 from monopole/dependOnNewPluginatorModule (Jeff Regan) def4f045 - Depend on new pluginator location. (Jeffrey Regan) 2f2408f1 - Merge pull request #1559 from monopole/compressCopyright (Jeff Regan) 3b9bcc48 - Compress copyright in the commands package. (Jeffrey Regan) d0429ff4 - Merge pull request #1557 from monopole/pluginatorModule (Jeff Regan) 33deefc3 - Copy pluginator to its own module. (Jeffrey Regan) 9b3de82b - Merge pull request #1506 from Liujingfang1/release (Jeff Regan) d217074f - Merge pull request #1550 from keleustes/apiversion (Kubernetes Prow Robot) 1d90ba7c - Fix typo in apiVersion yaml declaration (Jerome Brette) eeeb4c36 - Merge pull request #1547 from keleustes/extensions (Kubernetes Prow Robot) b1faa989 - Update Ingress apiVersion to networking.k8s.io/v1beta1 (Jerome Brette) d8250c9e - move test case (nimohunter) c9500466 - add transformer href (Wang(わん)) 0c32691e - Merge pull request #1537 from jaypipes/gomod-install-note (Kubernetes Prow Robot) 88b1d627 - Merge pull request #1541 from rtnpro/patch-1 (Jeff Regan) aec82066 - Update INSTALL.md (Jeff Regan) 20c2b53a - Merge pull request #1542 from monopole/tweakFilePathsInTest (Jeff Regan) 274b5c3b - Tweak file path handling and logging in test. (Jeffrey Regan) b1fdaa23 - Fix typo in transformerconfigs README (Ratnadeep Debnath) b5d5e70b - empty list or map item return error (nimohunter) 2e829853 - empty list or map item return error (nimohunter) 55941f57 - add note about GO111MODULE for source install (Jay Pipes) 9e226001 - empty list or map item return error (nimohunter) 77b63f96 - add release note for v3.2.0 (jingfangliu) </code></pre>

# Blog: v3.2.1

https://kubernetes-sigs.github.io/kustomize/blog/2019/09/26/v3.2.1/ Thu, 26 Sep 2019 00:00:00 +0000

https://kubernetes-sigs.github.io/kustomize/blog/2019/09/26/v3.2.1/

<p>This is a patch release, with no new features from 3.2.0.</p> <p>It reflects a change in dependence.</p> <p>The kustomize binary is now built as a client, with no special consideration, of the set of public packages represented by the Go module at [https://github.com/kubernetes-sigs/kustomize].</p> <p>kustomize the binary is now a client of the kustomize API represented by the public package surface presented by <code>https://github.com/kubernetes-sigs/kustomize/v{whatever}</code></p>

# Blog: v3.2.0

https://kubernetes-sigs.github.io/kustomize/blog/2019/09/17/v3.2.0/ Tue, 17 Sep 2019 00:00:00 +0000

https://kubernetes-sigs.github.io/kustomize/blog/2019/09/17/v3.2.0/

<h2 id="inline-patch">Inline Patch</h2> <p>Since this version, Kustomize allows inline patches in all three of <code>patchesStrategicMerge</code>, <code>patchesJson6902</code> and <code>patches</code>. Take a look at <a href="https://github.com/kubernetes-sigs/kustomize/tree/master/examples/examples/inlinePatch.md">inline patch</a>.</p> <h2 id="new-subcommand">New Subcommand</h2> <p>Since this version, one can create a kustomization.yaml file in a directory through a <code>create</code> subcommand.</p> <p>Create a new overlay from the base ../base</p> <pre><code>kustomize create --resources ../base </code></pre><p>Create a new kustomization detecing resources in the current directory</p> <pre><code>kustomize create --autodetect </code></pre><p>Once can also add all resources in the current directory recursively by</p> <pre><code>kustomize create --autodetect --recursive </code></pre><h3 id="new-example-generator">New Example Generator</h3> <p>A new example generator of using go-getter to download resources is added. Take a look at <a href="https://github.com/kubernetes-sigs/kustomize/tree/master/examples/goGetterGeneratorPlugin.md">go-getter generator</a>.</p>

# Blog: v3.1.0

https://kubernetes-sigs.github.io/kustomize/blog/2019/07/26/v3.1.0/ Fri, 26 Jul 2019 00:00:00 +0000

https://kubernetes-sigs.github.io/kustomize/blog/2019/07/26/v3.1.0/

<h2 id="extended-patches">Extended patches</h2> <p>Since this version, Kustomize allows applying one patch to multiple resources. This works for both Strategic Merge Patch and JSON Patch. Take a look at <a href="https://github.com/kubernetes-sigs/kustomize/tree/master/examples/patchMultipleObjects.md">patch multiple objects</a>.</p> <h2 id="improved-resource-matching">Improved Resource Matching</h2> <p>Multiple improvements have been made to allow the user to leverage &ldquo;namespace&rdquo; instead/or with &ldquo;name suffix/prefix&rdquo; to segregate resources.</p> <h3 id="patch-resolution-improvement">Patch resolution improvement</h3> <p>The following example demonstrates how using the namespace field in the patch definition, will let the user define two different patches against two different Deployment having the same &ldquo;deploy1&rdquo; name but in different namespaces in the same Kustomize context/folder. Unless the <code>namespace:</code> field has been specified in the kustomization.yaml, no namespace value will be handled as Kubernetes <code>default</code> namespace.</p> <div class="highlight"><pre style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-yaml" data-lang="yaml"><span style="color:#204a87;font-weight:bold">apiVersion</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>apps/v1<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">kind</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>Deployment<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">metadata</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>deploy1<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">namespace</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>main<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">spec</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">template</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">spec</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">containers</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span>- <span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>nginx<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">env</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span>- <span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>ANOTHERENV<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">value</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>TESTVALUE<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span>---<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">apiVersion</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>apps/v1<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">kind</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>Deployment<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">metadata</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>deploy1<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">namespace</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>production<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">spec</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">template</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">spec</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">containers</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span>- <span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>main<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">env</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span>- <span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>ANOTHERENV<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">value</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>PRODVALUE<span style="color:#f8f8f8;text-decoration:underline"> </span></code></pre></div><h3 id="variable-resolution-improvement">Variable resolution improvement</h3> <p>It is possible to add namespace field to the variable declaration. In the following example, two <code>Service</code> objects with the same <code>elasticsearch</code> name have been declared. Specifying the namespace in the objRef of the corresponding varriables, allows Kustomize to resovlve thoses variables. If the namespace is not specified, Kustomize will handle it has a &ldquo;wildcard&rdquo; value.</p> <p>Extract of kustomization.yaml:</p> <div class="highlight"><pre style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-yaml" data-lang="yaml"><span style="color:#204a87;font-weight:bold">vars</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span>- <span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>elasticsearch-test-protocol<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">objref</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">kind</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>Service<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>elasticsearch<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">namespace</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>test<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">apiVersion</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>v1<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">fieldref</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">fieldpath</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>spec.ports<span style="color:#000;font-weight:bold">[</span><span style="color:#0000cf;font-weight:bold">0</span><span style="color:#000;font-weight:bold">]</span>.protocol<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span>- <span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>elasticsearch-dev-protocol<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">objref</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">kind</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>Service<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>elasticsearch<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">namespace</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>dev<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">apiVersion</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>v1<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">fieldref</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">fieldpath</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>spec.ports<span style="color:#000;font-weight:bold">[</span><span style="color:#0000cf;font-weight:bold">0</span><span style="color:#000;font-weight:bold">]</span>.protocol<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span></code></pre></div><h3 id="simultaneous-change-of-names-and-namespaces">Simultaneous change of names and namespaces</h3> <p>Kustomize is now able to deal with simultaneous changes of name and namespace. Special attention has been paid the handling of:</p> <ul> <li>ClusterRoleBinding/RoleBinding &ldquo;subjects&rdquo; field,</li> <li>ValidatingWebhookConfiguration &ldquo;webhooks&rdquo; field.</li> </ul> <p>The user should be able to use a kustomization.yaml as shown in the example bellow even if ClusterRoleBind,RoleBinding and ValidatingWebookConfiguration are part of the resources he needs to declare.</p> <p>Extract of kustomization.yaml:</p> <div class="highlight"><pre style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-yaml" data-lang="yaml"><span style="color:#204a87;font-weight:bold">namePrefix</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>pfx-<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">nameSuffix</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>-sfx<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">namespace</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>testnamespace<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">resources</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span>...<span style="color:#f8f8f8;text-decoration:underline"> </span></code></pre></div><h3 id="resource-and-kustomize-context-matching">Resource and Kustomize Context matching</h3> <p>Kustomize is now able to support more aggregation patterns.</p> <p>If for instance, the top level of kustomization.yaml, is simply combining sub-components, (as in the following example), Kustomize has improved resource matching capabilities. This removes some of the constraints which were present on the utilization of prefix/suffix and namespace transformers in the individual components.</p> <div class="highlight"><pre style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-yaml" data-lang="yaml"><span style="color:#204a87;font-weight:bold">resources</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span>- ../component1<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span>- ../component2<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#f8f8f8;text-decoration:underline"></span>- ../component3<span style="color:#f8f8f8;text-decoration:underline"> </span></code></pre></div><h2 id="other-improvements">Other improvements</h2> <ul> <li>Image transformation has been improved. This allows the user to update the sha256 of an image with another sha256.</li> <li>Multiple default transformer configuration entries have been added, removing the need for the user to add them as part of the <code>configurations:</code> section of the kustomization.yaml.</li> <li><code>kustomize</code> help command has been tidied up.</li> </ul>

# Blog: v3.0.0

https://kubernetes-sigs.github.io/kustomize/blog/2019/07/03/v3.0.0/ Wed, 03 Jul 2019 00:00:00 +0000

https://kubernetes-sigs.github.io/kustomize/blog/2019/07/03/v3.0.0/

<p>This release is basically <a href="v2.1.0.md">v2.1.0</a>, with many post-v2.1.0 bugs fixed (in about 150 commits) and a <code>v3</code> in Go package paths.</p> <p>The major version increment to <code>v3</code> puts a new floor on a stable API for <a href="https://kubernetes-sigs.github.io/kustomize/docs/plugins">plugin</a> developers (both <em>Go</em> plugin developers and <em>exec</em> plugin developers who happen to use Go).</p> <h3 id="why-so-soon-after-v210">Why so soon after v2.1.0</h3> <p>We made a mistake - v2.1.0 should have been v3.0.0. Per the <a href="https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher">Go modules doc</a> (which have improved a great deal recently), a release that&rsquo;s already tagged v2 or higher should increment the major version when performing their first Go module-based release.</p> <p>This advice applies to kustomize, since it was already at major version 2 when it began using Go modules to state <em>its own</em> dependencies in v2.1.0.</p> <p>But the more important reason for <code>v3</code> is a change to the kustomize <a href="https://kubernetes-sigs.github.io/kustomize/kustomize/faq/versioningpolicy">versioning policy</a>, forced by the introduction of plugins.</p> <p>Historically, kustomize&rsquo;s <a href="https://kubernetes-sigs.github.io/kustomize/kustomize/faq/versioningpolicy">versioning policy</a> didn&rsquo;t involve Go modules and addressed <em>only</em> the command line tool&rsquo;s behavior and the fields in a kustomization file. The underlying packages were an implementation detail, not under semantic versioning, because they weren&rsquo;t intended for export (and should have all been under <code>internal</code>). Thus although the v2.1.0 CLI is backward compatible with v2.0.3, the underlying package APIs are not.</p> <p>With Go modules, the <code>go</code> tool must assume that Go packages respect <a href="https://semver.org">semantic versioning</a>, so it can perform <a href="https://research.swtch.com/vgo-mvs">minimal version selection</a>.</p> <p>With the introduction of alpha plugins, kustomize sub-packages - in particular <code>loader</code> and <code>resmap</code> - become part of an API formally exposed to plugin authors, and so must be semantically versioned. This allows plugins defined in other repositories to clarify that they depend on kustomize v3.0.0, and not see confusing errors arising from incompatibilities between v2.1.0 and v2.0.3. Hence, the jump to v3.</p> <p>Aside - the set of kustomize packages outside <code>internal</code> is too large, and over time, informed by package use, this API surface must shrink. Such shrinkage will trigger a major version increment.</p>

# Blog: v2.1.0

https://kubernetes-sigs.github.io/kustomize/blog/2019/06/18/v2.1.0/ Tue, 18 Jun 2019 00:00:00 +0000

https://kubernetes-sigs.github.io/kustomize/blog/2019/06/18/v2.1.0/

<p>Go modules, resource ordering respected, generator and transformer plugins, eased loading restrictions, the notion of inventory, eased replica count modification. About ~90 issues closed since <a href="https://github.com/kubernetes-sigs/kustomize/releases/tag/v1.0.9releases/tag/v2.0.3">v2.0.3</a> in ~400 commits.</p> <p>Download <a href="https://github.com/kubernetes-sigs/kustomize/releases/tag/v1.0.9releases/tag/v2.1.0">here</a>.</p> <h2 id="go-modules">Go modules</h2> <p><img src="https://kubernetes-sigs.github.io/kustomize/kustomize/images/goModules.png" alt="gopher with boxes"></p> <p>Kustomize now defines its dependencies in a top level <code>go.mod</code> file. This is the first step towards a package structure intentially exported as one or more <a href="https://github.com/golang/go/wiki/Modules">Go modules</a> for use in other programs (kubectl, kubebuilder, etc.) and in kustomize plugins (see below).</p> <h2 id="resource-ordering">Resource ordering</h2> <p><img src="https://kubernetes-sigs.github.io/kustomize/kustomize/images/sorted.png" alt="sort order retained"></p> <p>Kustomize now retains the depth-first order of resources as read, a frequently requested feature.</p> <p>This means resource order can be controlled by editting kustomization files. This is also vital to applying user-defined transformations (plugins) in a particular order.</p> <p>Nothing needs to be done to activate this; it happens automatically.</p> <p>The <code>build</code> command now accepts a <code>--reorder</code> flag with values <code>legacy</code> and <code>none</code>, with a default value of <code>legacy</code>.</p> <p><code>legacy</code> means apply an ordering based on GVK, that currently emits <code>Namespace</code> objects first, and <code>ValidatingWebhookConfiguration</code> objects last. This means that despite automatic retention of load order, your <code>build</code> output won&rsquo;t change by default.</p> <p><code>none</code> means <em>don&rsquo;t</em> reorder the resources before output. Specify this to see output order respect input order.</p> <h2 id="generator-and-transformer-plugins">Generator and transformer plugins</h2> <p><img src="https://kubernetes-sigs.github.io/kustomize/kustomize/images/plugins.png" alt="kid putting knife in electrical outlet"></p> <p>Since the beginning (as <code>kinflate</code> back in Sep 2017), kustomize has read or generated resources, applied a series of pipelined transformation to them, and emitted the result to <code>stdout</code>.</p> <p>At that time, the only way to change the behavior of a generator (e.g. a secret generator), or change the behavior of a transformer (e.g. a name changer, or json patcher), was to modify source code and put out a release.</p> <p><a href="https://github.com/kubernetes-sigs/kustomize/releases/tag/v1.0.9">v1.0.9</a> introduced <a href="https://github.com/kubernetes-sigs/kustomize/tree/master/examples/generatorOptions.md">generator options</a> as a means to change the behavior of the only two generators available at the time - Secret and ConfigMap generators. It also introduced <a href="https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs">transformer configs</a> as a way to fine tune the targets of transformations (e.g. to which fields <em>selectors</em> should be added). Most of the feature requests for kustomize revolve around changing the behavior of the builtin generators and transformers.</p> <p><a href="https://github.com/kubernetes-sigs/kustomize/releases/tag/v1.0.9releases/tag/v2.1.0">v2.1.0</a> adds an <em>alpha</em> plugin framework, that encourages users to write their own generators or transformers, <em>declaring them as kubernetes objects just like everything else</em>, and apply them as part of the <code>kustomize build</code> process.</p> <p>To inform the API exposed to plugins, and to confirm that the plugin framework can offer plugin authors the same capabilities as builtin operations, all the builtin generators and tranformers have been converted to plugin form (with one exceptions awaiting Go module refinements). This means that adding, say, a <code>secretGenerator</code> or <code>commonAnnotations</code> directive to your kustomization will (in <a href="https://github.com/kubernetes-sigs/kustomize/releases/tag/v1.0.9releases/tag/v2.1.0">v2.1.0</a>) trigger execution of <a href="https://github.com/kubernetes-sigs/kustomize/tree/master/plugin/builtin">code committed as a plugin</a>.</p> <p>For more information, see the <a href="plugins">kustomize plugin documentation</a>.</p> <h2 id="remove-load-restrictions">Remove load restrictions</h2> <p><img src="https://kubernetes-sigs.github.io/kustomize/kustomize/images/abandonedTrainingWheels.png" alt="removed training wheels"></p> <p>The following usage:</p> <pre><code>kustomize build --load_restrictor none $target </code></pre><p>allows a <code>kustomization.yaml</code> file used in this build to refer to files outside its own directory (i.e. outside its <a href="https://kubernetes-sigs.github.io/kustomize/kustomize/api-reference/glossary#kustomization-root">root</a>).</p> <p>This is an opt-in to suppress a security feature that denies this precise behavior.</p> <p>This feature should only be used to allow multiple overlays (e.g. prod, staging and dev) to share a patch file. To share <em>resources</em>, use a relative path or URL to a kustomization directory in the <code>resources</code> directive.</p> <h2 id="inventory-generation-for-pruning">Inventory generation for pruning</h2> <p><img src="https://kubernetes-sigs.github.io/kustomize/kustomize/images/pruning.png" alt="pruning dead branches"></p> <p><em>Alpha</em></p> <p>Users can add an <code>inventory</code> stanza to their kustomization file, to add a special <em>inventory object</em> to the <code>build</code> result.</p> <p>This object applies to the cluster along with everything else in the build result and can be used by other clients to intelligently <em>prune</em> orphaned cluster resources.</p> <p>For more information see the <a href="https://github.com/kubernetes-sigs/kustomize/tree/master/docs/inventory_object.md">kustomize inventory object documentation</a>.</p> <h2 id="field-changes--deprecations">Field changes / deprecations</h2> <h3 id="resources-expanded-bases-deprecated"><code>resources</code> expanded, <code>bases</code> deprecated</h3> <p>The <code>resources</code> field has been generalized; it now accepts what formerly could only be specified in the <code>bases</code> field.</p> <p>This change was made to allow users fine control over resource processing order. With a distinct <code>bases</code> field, bases had to be loaded separately from resources as a group. Now, base loading may be interleaved as desired with the loading of resource files from the current directory. <a href="#resource-ordering">Resource ordering</a> had to be respected before this feature could be introduced.</p> <p>The <code>bases</code> field is now deprecated, and will be deleted in some future major release. Manage the deprecation simply moving the arguments of the <code>bases</code> field to the <code>resources</code> field in the desired order, e.g.</p> <blockquote> <pre><code>resources: - someResouceFile.yaml - someOtherResourceFile.yaml bases: - ../../someBaseDir </code></pre></blockquote> <p>could become</p> <blockquote> <pre><code>resources: - someResouceFile.yaml - ../../someBaseDir - someOtherResourceFile.yaml </code></pre></blockquote> <p>The <code>kustomized edit fix</code> command will do this for you, though it will always put the bases at the end.</p> <p>As an aside, the <code>resources</code>, <code>generators</code> and <code>transformers</code> fields now all accept the same argument format.</p> <blockquote> <p>Each field&rsquo;s argument is a <em>string list</em>, where each entry is either a <em>resource</em> (a relative path to a YAML file) or a <a href="https://kubernetes-sigs.github.io/kustomize/kustomize/api-reference/glossary#kustomization"><em>kustomization</em></a> (a path or URL pointing to a directory with a kustomization file). A kustomization directory used in this context is called a <a href="https://kubernetes-sigs.github.io/kustomize/kustomize/api-reference/glossary#base"><em>base</em></a>.</p> </blockquote> <p>The fact that the <code>generators</code> and <code>transformers</code> field accept <a href="https://kubernetes-sigs.github.io/kustomize/kustomize/api-reference/glossary#base">bases</a> and the fact that generator and transformer configuration objects are just normal k8s resources means that one can generate or transform a generator or a transformer (see <a href="https://github.com/kubernetes-sigs/kustomize/tree/master/api/internal/target/transformerplugin_test.go">TestTransformerTransformers</a>).</p> <h3 id="replicas-field"><code>replicas</code> field</h3> <p>The common task of patching a deployment to edit the number of replicas is now made easier with the new <a href="https://kubernetes-sigs.github.io/kustomize/kustomize/api-reference/kustomization/replicas">replicas</a> field.</p> <h3 id="envs-field"><code>envs</code> field</h3> <p>An <code>envs</code> sub-field has been added to both <code>configMapGenerator</code> and <code>secretGenerator</code>, replacing the now deprecated (and singular) <code>env</code> field. The new field accepts lists, just like its sibling fields <code>files</code> and <code>literals</code>.</p> <p>Optionally use <code>kustomize edit fix</code> to merge singular <code>env</code> field into a plural field.</p>

# Blog: v2.0.0

https://kubernetes-sigs.github.io/kustomize/blog/2019/02/05/v2.0.0/ Tue, 05 Feb 2019 00:00:00 +0000

https://kubernetes-sigs.github.io/kustomize/blog/2019/02/05/v2.0.0/

<p>After security review, a field used in secret generation (see below) was removed from the definition of a kustomization file with no mechanism to convert it to a new form. Also, the set of files accessible from a kustomization file has been further constrained.</p> <p>Per the <a href="https://kubernetes-sigs.github.io/kustomize/kustomize/faq/versioningpolicy">versioning policy</a>, backward incompatible changes trigger an increment of the major version number, hence we go from 1.0.11 to 2.0.0. We&rsquo;re taking this major version increment opportunity to remove some already deprecated fields, and the code paths associated with them.</p> <h2 id="backward-incompatible-changes">Backward Incompatible Changes</h2> <h3 id="kustomization-path-constraints">Kustomization Path Constraints</h3> <p>A kustomization file can specify paths to other files, including resources, patches, configmap generation data, secret generation data and bases. In the case of a base, the path can be a git URL instead.</p> <p>In 1.x, these paths had to be relative to the current kustomization directory (the location of the kustomization file used in the <code>build</code> command).</p> <p>In 2.0, bases can continue to specify, via relative paths, kustomizations outside the current kustomization directory. But non-base paths are constrained to terminate in or below the current kustomization directory. Further, bases specified via a git URL may not reference files outside of the directory used to clone the repository.</p> <h3 id="kustomization-field-removals">Kustomization Field Removals</h3> <h4 id="patches">patches</h4> <p><code>patches</code> was deprecated and replaced by <code>patchesStrategicMerge</code> when <code>patchesJson6902</code> was introduced. In Kustomize 2.0.0, <code>patches</code> is removed. Please use <code>patchesStrategicMerge</code> instead.</p> <h4 id="imagetags">imageTags</h4> <p><code>imageTags</code> is replaced by <code>images</code> since <code>images</code> can provide more features to change image names, registries, tags and digests.</p> <h4 id="secretgeneratorcommands">secretGenerator/commands</h4> <p><code>commands</code> is removed from SecretGenerator due to a <a href="https://docs.google.com/document/d/1FYgLVdq-siB_Cef9yuQBmit0PbrE8lsyTBdGI2eA2y8/edit">security concern</a>. One can use <code>files</code> or <code>literals</code>, similar to ConfigMapGenerator, to generate a secret.</p> <pre><code>secretGenerator: - name: app-tls files: - secret/tls.cert - secret/tls.key type: &quot;kubernetes.io/tls&quot; </code></pre><h2 id="compatible-changes-new-features">Compatible Changes (New Features)</h2> <p>As this release is triggered by a security change, there are no major new features to announce. A few things that are worth mentioning in this release are:</p> <ul> <li> <p>More than <em>40</em> issues closed since 1.0.11 release (including many extensions to transformation rules).</p> </li> <li> <p>Users can run <code>kustomize edit fix</code> to migrate a kustomization file working with previous versions to one working with 2.0.0. For example, a kustomization.yaml with following content</p> <pre><code>patches: - deployment-patch.yaml imageTags: - name: postgres newTag: v1 </code></pre><p>will be converted to</p> <pre><code>apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization patchesStrategicMerge: - deployment-patch.yaml images: - name: postgres newTag: v1 </code></pre></li> <li> <p>Kustomization filename</p> <p>In previous versions, the name of a kustomization file had to be <code>kustomization.yaml</code>. Kustomize allows <code>kustomization.yaml</code>, <code>kustomization.yml</code> and <code>Kustomization</code>. In a directory, only one of those filenames is allowed. If there are more than one found, Kustomize will exit with an error. Please select the best filename for your use cases.</p> </li> <li> <p>Cancelled plans to deprecate applying prefix/suffix to namespace. The deprecation warning</p> <pre><code>Adding nameprefix and namesuffix to Namespace resource will be deprecated in next release. </code></pre><p>was removed.</p> </li> </ul>

# Blog: v1.0.1

https://kubernetes-sigs.github.io/kustomize/blog/2018/05/21/v1.0.1/ Mon, 21 May 2018 00:00:00 +0000

https://kubernetes-sigs.github.io/kustomize/blog/2018/05/21/v1.0.1/

<p>Initial release after move from github.com/kubernetes/kubectl to github.com/kubernetes-sigs/kustomize.</p> <p>History</p> <ul> <li>May 2018: v1.0 after move to github.com/kubernetes-sigs/kubectl from github.com/kubernetes/kubectl. Has kustomization file, bases, overlays, basic transforms.</li> <li>Apr 2018: s/kinflate/kustomize/, s/manifest/kustomization/</li> <li>Oct 2017: s/kexpand/kinflate/</li> <li>Sep 2017: kexpand <a href="https://github.com/kubernetes/kubectl/pull/65">starts</a> in github.com/kubernetes/kubectl</li> <li>Aug 2017: <a href="https://docs.google.com/document/d/1cLPGweVEYrVqQvBLJg6sxV-TrE5Rm2MNOBA_cxZP2WU">DAM</a> authored by Brian Grant</li> </ul>