Deprecate 'bases:' field.

This commit is contained in:
Jeffrey Regan
2019-06-18 07:28:58 -07:00
parent 0dbe78149d
commit cc531af665
24 changed files with 156 additions and 152 deletions

View File

@@ -9,9 +9,8 @@ What existing things should be customized.
| Field | Type | Explanation |
|---|---|---|
|[resources](#resources) | list |completely specified k8s API objects, e.g. deployment.yaml, configmap.yaml, etc|
|[bases](#bases)| list |paths or github URLs specifying directories containing a kustomization. These bases may be subjected to more customization, or merely included in the output.|
|[CRDs](#crds)| list |custom resource definition files, to allow specification of the custom resources in the resources list. |
|[resources](#resources) | list |Files containing k8s API objects, or directories containing other kustomizations. |
|[CRDs](#crds)| list |Custom resource definition files, to allow specification of the custom resources in the resources list. |
## Generators
@@ -62,33 +61,15 @@ If missing, this field's value defaults to
```
apiVersion: kustomize.config.k8s.io/v1beta1
```
### bases
Each entry in this list should resolve to a directory
containing a kustomization file, else the
customization fails.
The entry could be a relative path pointing to a local directory
or a url pointing to a directory in a remote repo.
The url should follow hashicorp/go-getter URL format
https://github.com/hashicorp/go-getter#url-format
The presence of this field means this file (the file
you a reading) is an _overlay_ that further
customizes information coming from these _bases_.
Typical use case: a dev, staging and production
environment that are mostly identical but differing
crucial ways (image tags, a few server arguments,
etc. that differ from the common base).
```
bases:
- ../../base
- github.com/kubernetes-sigs/kustomize//examples/multibases?ref=v1.0.6
- github.com/kubernets-sigs/kustomize//examples/helloWorld?ref=test-branch
```
The `bases` field was deprecated in v2.1.0.
Move entries into the [resources](#resources)
field. This allows bases - which are still a
[central concept](glossary.md#base) - to be
ordered relative to other input resources.
### commonLabels
@@ -288,11 +269,10 @@ Each entry in this list should be a relative path
resolving to a partial or complete resource
definition file.
The names in these (possibly partial) resource files
must match names already loaded via the `resources`
field or via `resources` loaded transitively via the
`bases` entries. These entries are used to _patch_
(modify) the known resources.
The names in these (possibly partial) resource
files must match names already loaded via the
`resources` field. These entries are used to
_patch_ (modify) the known resources.
Small patches that do one thing are best, e.g. modify
a memory request/limit, change an env var in a
@@ -389,18 +369,37 @@ For more complex use cases, revert to using a patch.
### resources
Each entry in this list must resolve to an existing
resource definition in YAML. These are the resource
files that kustomize reads, modifies and emits as a
YAML string, with resources separated by document
markers ("---").
Each entry in this list must be a path to a
_file_, or a path (or URL) refering to another
kustomization _directory_, e.g.
```
resource:
- some-service.yaml
- myNamespace.yaml
- sub-dir/some-deployment.yaml
- ../../commonbase
- github.com/kubernetes-sigs/kustomize//examples/multibases?ref=v1.0.6
- deployment.yaml
- github.com/kubernets-sigs/kustomize//examples/helloWorld?ref=test-branch
```
Resources will be read and processed in
depth-first order.
Files should contain k8s resources in YAML form.
A file may contain multiple resources separated by
the document marker `---`. File paths should be
specified _relative_ to the directory holding the
kustomization file containing the `resources`
field.
[hashicorp URL]: https://github.com/hashicorp/go-getter#url-format
Directory specification can be relative, absolute,
or part of a URL. URL specifications should
follow the [hashicorp URL] format. The directory
must contain a `kustomization.yaml` file.
### secretGenerator

View File

@@ -62,9 +62,26 @@ commonAnnotations:
# 一个 YAML 资源描述文件可以含有多个由(“---”)分隔的资源。
# kustomize 将读取这些YAML文件中的资源对其进行修改并
# 发布在 kustomize 的输出中。
#
# 此列表中的每个条目都应解析为包含 kustomization 文件的目录,否则定制将失败
#
# 该条目可以是指向本地目录的相对路径
# 也可以是指向远程仓库中的目录的 URL
# URL 应该遵循 hashicorp/go-getter 中的 URL 格式
# https://github.com/hashicorp/go-getter#url-format
#
# 此字段的存在意味着此文件(您正在阅读的文件)是 _overlay_
# 它将进一步定制这些来自 _bases_ 文件中的配置
#
# 典型用例:开发,演示和生产环境
# 这些环境大部分相同但有些关键方式存在差异(镜像标签,一些服务器参数等,与公共 base 不同的配置)
resources:
- some-service.yaml
- sub-dir/some-deployment.yaml
- ../../base
- github.com/kubernetes-sigs/kustomize/examples/multibases?ref=v1.0.6
- github.com/Liujingfang1/mysql
- github.com/Liujingfang1/kustomize/examples/helloWorld?ref=test-branch
# 列表中的每个条目都将创建一个 ConfigMap 它是n个 ConfigMap 的生成器)
# 下面的示例创建了两个 ConfigMaps
@@ -113,24 +130,6 @@ generatorOptions:
# disableNameSuffixHash 为 true 时将禁止默认的在名称后添加哈希值后缀的行为
disableNameSuffixHash: true
# 此列表中的每个条目都应解析为包含 kustomization 文件的目录,否则定制将失败
#
# 该条目可以是指向本地目录的相对路径
# 也可以是指向远程仓库中的目录的 URL
# URL 应该遵循 hashicorp/go-getter 中的 URL 格式
# https://github.com/hashicorp/go-getter#url-format
#
# 此字段的存在意味着此文件(您正在阅读的文件)是 _overlay_
# 它将进一步定制这些来自 _bases_ 文件中的配置
#
# 典型用例:开发,演示和生产环境
# 这些环境大部分相同但有些关键方式存在差异(镜像标签,一些服务器参数等,与公共 base 不同的配置)
bases:
- ../../base
- github.com/kubernetes-sigs/kustomize/examples/multibases?ref=v1.0.6
- github.com/Liujingfang1/mysql
- github.com/Liujingfang1/kustomize/examples/helloWorld?ref=test-branch
# 此列表中的每个条目都应可以解析为部分或完整的资源定义文件
#
# 这些(也可能是部分的)资源文件中的 name 必须与已经通过 `resources` 加载的 name 字段匹配

View File

@@ -71,7 +71,7 @@ mkdir -p $DEMO_HOME/breakfast/overlays/alice
cat <<EOF >$DEMO_HOME/breakfast/overlays/alice/kustomization.yaml
commonLabels:
who: alice
bases:
resources:
- ../../base
patchesStrategicMerge:
- temperature.yaml
@@ -94,7 +94,7 @@ mkdir -p $DEMO_HOME/breakfast/overlays/bob
cat <<EOF >$DEMO_HOME/breakfast/overlays/bob/kustomization.yaml
commonLabels:
who: bob
bases:
resources:
- ../../base
patchesStrategicMerge:
- topping.yaml

View File

@@ -191,7 +191,7 @@ dbpassword=mothersMaidenName
EOF
cat <<EOF >$OVERLAYS/development/kustomization.yaml
bases:
resources:
- ../../base
namePrefix: dev-
nameSuffix: -v1
@@ -273,7 +273,7 @@ dbpassword=thisShouldProbablyBeInASecretInstead
EOF
cat <<EOF >$OVERLAYS/production/kustomization.yaml
bases:
resources:
- ../../base
namePrefix: prod-
configMapGenerator:

View File

@@ -66,7 +66,7 @@ commonLabels:
org: acmeCorporation
commonAnnotations:
note: Hello, I am staging!
bases:
resources:
- ../../base
patchesStrategicMerge:
- map.yaml

View File

@@ -148,7 +148,7 @@ commonLabels:
org: acmeCorporation
commonAnnotations:
note: Hello, I am staging!
bases:
resources:
- ../../base
patchesStrategicMerge:
- map.yaml
@@ -189,7 +189,7 @@ commonLabels:
org: acmeCorporation
commonAnnotations:
note: Hello, I am production!
bases:
resources:
- ../../base
patchesStrategicMerge:
- deployment.yaml

View File

@@ -1,4 +1,4 @@
bases:
resources:
- ../../base
patchesStrategicMerge:
- deployment.yaml

View File

@@ -1,9 +1,9 @@
bases:
- ../../base
resources:
- ../../base
patchesStrategicMerge:
- deployment.yaml
nameprefix: staging-
namePrefix: staging-
configMapGenerator:
- name: env-config
- name: env-config
files:
- config.env

View File

@@ -1,12 +1,22 @@
# Demo: multibases with a common base
`kustomize` encourages defining multiple variants - e.g. dev, staging and prod, as overlays on a common base.
`kustomize` encourages defining multiple variants -
e.g. dev, staging and prod,
as overlays on a common base.
It's possible to create an additional overlay to compose these variants together - just declare the overlays as the bases of a new kustomization.
It's possible to create an additional overlay to
compose these variants together - just declare the
overlays as the bases of a new kustomization.
This is also a means to apply a common label or annotation across the variants, if for some reason the base isn't under your control. It also allows one to define a left-most namePrefix across the variants - something that cannot be done by modifying the common base.
This is also a means to apply a common label or
annotation across the variants, if for some reason
the base isn't under your control. It also allows
one to define a left-most namePrefix across the
variants - something that cannot be
done by modifying the common base.
The following demonstrates this using a base that's just one pod.
The following demonstrates this using a base
that is just a single pod.
Define a place to work:
@@ -47,7 +57,7 @@ DEV=$DEMO_HOME/dev
mkdir $DEV
cat <<EOF >$DEV/kustomization.yaml
bases:
resources:
- ./../base
namePrefix: dev-
EOF
@@ -60,7 +70,7 @@ STAG=$DEMO_HOME/staging
mkdir $STAG
cat <<EOF >$STAG/kustomization.yaml
bases:
resources:
- ./../base
namePrefix: stag-
EOF
@@ -73,7 +83,7 @@ PROD=$DEMO_HOME/production
mkdir $PROD
cat <<EOF >$PROD/kustomization.yaml
bases:
resources:
- ./../base
namePrefix: prod-
EOF
@@ -83,7 +93,7 @@ Then define a _Kustomization_ composing three variants together:
<!-- @makeTopLayer @test -->
```
cat <<EOF >$DEMO_HOME/kustomization.yaml
bases:
resources:
- ./dev
- ./staging
- ./production

View File

@@ -1,4 +1,3 @@
bases:
- ./../base
resources:
- ../base
namePrefix: dev-

View File

@@ -1,6 +1,5 @@
bases:
- ./dev
- ./staging
- ./production
resources:
- dev
- staging
- production
namePrefix: cluster-a-

View File

@@ -2,7 +2,9 @@
`kustomize` supports defining multiple variants with different namespace, as overlays on a common base.
It's possible to create an additional overlay to compose these variants together - just declare the overlays as the bases of a new kustomization. The following demonstrates this using a base that's just one pod.
It's possible to create an additional overlay to compose these variants
together - just declare the overlays as the bases of a new kustomization. The
following demonstrates this using a base that's just one pod.
Define a place to work:
@@ -43,10 +45,9 @@ NSA=$DEMO_HOME/namespace-a
mkdir $NSA
cat <<EOF >$NSA/kustomization.yaml
bases:
- ./../base
resources:
- namespace.yaml
- ../base
namespace: namespace-a
EOF
@@ -65,10 +66,9 @@ NSB=$DEMO_HOME/namespace-b
mkdir $NSB
cat <<EOF >$NSB/kustomization.yaml
bases:
- ./../base
resources:
- namespace.yaml
- ../base
namespace: namespace-b
EOF
@@ -84,9 +84,9 @@ Then define a _Kustomization_ composing two variants together:
<!-- @makeTopLayer @test -->
```
cat <<EOF >$DEMO_HOME/kustomization.yaml
bases:
- ./namespace-a
- ./namespace-b
resources:
- namespace-a
- namespace-b
EOF
```

View File

@@ -1,4 +1,3 @@
bases:
- ./../base
resources:
- ../base
namePrefix: prod-

View File

@@ -1,4 +1,3 @@
bases:
- ./../base
resources:
- ../base
namePrefix: staging-

View File

@@ -39,7 +39,7 @@ A base can be a URL:
DEMO_HOME=$(mktemp -d)
cat <<EOF >$DEMO_HOME/kustomization.yaml
bases:
resources:
- github.com/kubernetes-sigs/kustomize//examples/multibases?ref=v1.0.6
namePrefix: remote-
EOF

View File

@@ -1,4 +1,4 @@
bases:
resources:
- ../../base
patchesStrategicMerge:
- patch.yaml

View File

@@ -1,4 +1,4 @@
bases:
resources:
- ../../base
namePrefix: staging-
configMapGenerator:

View File

@@ -44,17 +44,19 @@ curl -s -o "$MYSQL_HOME/#1.yaml" \
```
### Create kustomization.yaml
Create a new kustomization with two bases:
Create a new kustomization with two bases,
`wordpress` and `mysql`:
<!-- @createKustomization @test -->
```
cat <<EOF >$DEMO_HOME/kustomization.yaml
bases:
- wordpress
- mysql
resources:
- wordpress
- mysql
namePrefix: demo-
patchesStrategicMerge:
- patch.yaml
- patch.yaml
EOF
```

View File

@@ -1,17 +1,17 @@
bases:
- wordpress
- mysql
resources:
- wordpress
- mysql
patchesStrategicMerge:
- patch.yaml
- patch.yaml
namePrefix: demo-
vars:
- name: WORDPRESS_SERVICE
- name: WORDPRESS_SERVICE
objref:
kind: Service
name: wordpress
apiVersion: v1
- name: MYSQL_SERVICE
- name: MYSQL_SERVICE
objref:
kind: Service
name: mysql

View File

@@ -136,7 +136,7 @@ commonLabels:
org: acmeCorporation
commonAnnotations:
note: Hello, I am staging!
bases:
resources:
- ../../base
patchesStrategicMerge:
- map.yaml
@@ -175,7 +175,7 @@ commonLabels:
org: acmeCorporation
commonAnnotations:
note: Hello, I am production!
bases:
resources:
- ../../base
patchesStrategicMerge:
- deployment.yaml

View File

@@ -86,10 +86,10 @@ func (o *addBaseOptions) RunAddBase(fSys fs.FileSystem) error {
if !fSys.Exists(path) {
return errors.New(path + " does not exist")
}
if kustfile.StringInSlice(path, m.Bases) {
if kustfile.StringInSlice(path, m.Resources) {
return fmt.Errorf("base %s already in kustomization file", path)
}
m.Bases = append(m.Bases, path)
m.Resources = append(m.Resources, path)
}

View File

@@ -133,6 +133,7 @@ func TestPreserveComments(t *testing.T) {
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../namespaces
- pod.yaml
- service.yaml
# something you may want to keep
@@ -144,8 +145,6 @@ vars:
apiVersion: v1
kind: Service
name: my-service
bases:
- ../namespaces
# some descriptions for the patches
patchesStrategicMerge:
- service.yaml
@@ -176,10 +175,11 @@ func TestPreserveCommentsWithAdjust(t *testing.T) {
# shem qing some comments
# Some comments
# This is some comment we should preserve
# don't delete it
resources:
RESOURCES:
- ../namespaces
- pod.yaml
# See which field this comment goes into
- service.yaml
@@ -197,9 +197,6 @@ vars:
kind: Service
name: my-service
BASES:
- ../namespaces
# some descriptions for the patches
patchesStrategicMerge:
@@ -214,11 +211,12 @@ generatorOptions:
# shem qing some comments
# Some comments
# This is some comment we should preserve
# don't delete it
# See which field this comment goes into
resources:
- ../namespaces
- pod.yaml
- service.yaml
@@ -235,9 +233,6 @@ vars:
kind: Service
name: my-service
bases:
- ../namespaces
# some descriptions for the patches
patchesStrategicMerge:
@@ -263,7 +258,9 @@ generatorOptions:
}
bytes, _ := fSys.ReadFile(mf.path)
if !reflect.DeepEqual(expected, bytes) {
t.Fatal("written kustomization with comments is not the same as original one\n", string(bytes))
if string(expected) != string(bytes) {
t.Fatalf(
"expected =\n%s\n\nactual =\n%s\n",
string(expected), string(bytes))
}
}

View File

@@ -210,10 +210,6 @@ func (kt *KustTarget) shouldAddHashSuffixesToGeneratedResources() bool {
func (kt *KustTarget) AccumulateTarget() (
ra *accumulator.ResAccumulator, err error) {
ra = accumulator.MakeEmptyAccumulator()
err = kt.accumulateResources(ra, kt.kustomization.Bases)
if err != nil {
return nil, errors.Wrap(err, "accumulating bases")
}
err = kt.accumulateResources(ra, kt.kustomization.Resources)
if err != nil {
return nil, errors.Wrap(err, "accumulating resources")

View File

@@ -97,7 +97,8 @@ type Kustomization struct {
//
// Resources specifies relative paths to files holding YAML representations
// of kubernetes API objects. URLs and globs not supported.
// of kubernetes API objects, or specifcations of other kustomizations
// via relative paths, absolute paths, or URLs.
Resources []string `json:"resources,omitempty" yaml:"resources,omitempty"`
// Crds specifies relative paths to Custom Resource Definition files.
@@ -106,9 +107,9 @@ type Kustomization struct {
// CRDs themselves are not modified.
Crds []string `json:"crds,omitempty" yaml:"crds,omitempty"`
// Bases are relative paths or github repository URLs specifying a
// directory containing a kustomization.yaml file.
// URL format: https://github.com/hashicorp/go-getter#url-format
// Deprecated.
// Anything that would have been specified here should
// be specified in the Resources field instead.
Bases []string `json:"bases,omitempty" yaml:"bases,omitempty"`
//
@@ -180,6 +181,10 @@ func (k *Kustomization) FixKustomizationPostUnmarshalling() {
k.SecretGenerator[i].EnvSource = ""
}
}
for _, b := range k.Bases {
k.Resources = append(k.Resources, b)
}
k.Bases = nil
}
func (k *Kustomization) EnforceFields() []string {