mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-05-17 18:25:26 +00:00
665 lines
55 KiB
XML
665 lines
55 KiB
XML
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
||
<channel>
|
||
<title>Kustomize – Kustomize</title>
|
||
<link>https://kubernetes-sigs.github.io/kustomize/</link>
|
||
<description>Recent content on Kustomize</description>
|
||
<generator>Hugo -- gohugo.io</generator>
|
||
|
||
<atom:link href="https://kubernetes-sigs.github.io/kustomize/index.xml" rel="self" type="application/rss+xml" />
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<item>
|
||
<title>Blog: v3.3.0</title>
|
||
<link>https://kubernetes-sigs.github.io/kustomize/blog/2019/10/24/v3.3.0/</link>
|
||
<pubDate>Thu, 24 Oct 2019 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://kubernetes-sigs.github.io/kustomize/blog/2019/10/24/v3.3.0/</guid>
|
||
<description>
|
||
|
||
|
||
<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>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Blog: v3.2.1</title>
|
||
<link>https://kubernetes-sigs.github.io/kustomize/blog/2019/09/26/v3.2.1/</link>
|
||
<pubDate>Thu, 26 Sep 2019 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://kubernetes-sigs.github.io/kustomize/blog/2019/09/26/v3.2.1/</guid>
|
||
<description>
|
||
|
||
|
||
<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>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Blog: v3.2.0</title>
|
||
<link>https://kubernetes-sigs.github.io/kustomize/blog/2019/09/17/v3.2.0/</link>
|
||
<pubDate>Tue, 17 Sep 2019 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://kubernetes-sigs.github.io/kustomize/blog/2019/09/17/v3.2.0/</guid>
|
||
<description>
|
||
|
||
|
||
<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>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Blog: v3.1.0</title>
|
||
<link>https://kubernetes-sigs.github.io/kustomize/blog/2019/07/26/v3.1.0/</link>
|
||
<pubDate>Fri, 26 Jul 2019 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://kubernetes-sigs.github.io/kustomize/blog/2019/07/26/v3.1.0/</guid>
|
||
<description>
|
||
|
||
|
||
<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>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Blog: v3.0.0</title>
|
||
<link>https://kubernetes-sigs.github.io/kustomize/blog/2019/07/03/v3.0.0/</link>
|
||
<pubDate>Wed, 03 Jul 2019 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://kubernetes-sigs.github.io/kustomize/blog/2019/07/03/v3.0.0/</guid>
|
||
<description>
|
||
|
||
|
||
<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>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Blog: v2.1.0</title>
|
||
<link>https://kubernetes-sigs.github.io/kustomize/blog/2019/06/18/v2.1.0/</link>
|
||
<pubDate>Tue, 18 Jun 2019 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://kubernetes-sigs.github.io/kustomize/blog/2019/06/18/v2.1.0/</guid>
|
||
<description>
|
||
|
||
|
||
<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>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Blog: v2.0.0</title>
|
||
<link>https://kubernetes-sigs.github.io/kustomize/blog/2019/02/05/v2.0.0/</link>
|
||
<pubDate>Tue, 05 Feb 2019 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://kubernetes-sigs.github.io/kustomize/blog/2019/02/05/v2.0.0/</guid>
|
||
<description>
|
||
|
||
|
||
<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>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Blog: v1.0.1</title>
|
||
<link>https://kubernetes-sigs.github.io/kustomize/blog/2018/05/21/v1.0.1/</link>
|
||
<pubDate>Mon, 21 May 2018 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://kubernetes-sigs.github.io/kustomize/blog/2018/05/21/v1.0.1/</guid>
|
||
<description>
|
||
|
||
|
||
<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>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
</channel>
|
||
</rss>
|