内置插件
内置插件包括生成器和转化器。
每个插件都可以通过如下两种方式触发:
-
通过 kustomization 文件的字段隐式触发插件,例如
AnnotationsTransformer
就是由commonAnnotations
字段触发的。 -
通过
generators
或transformers
字段显式触发插件(通过指定插件的配置文件)。
直接使用 kustomization.yaml
文件中的字段比如 commonLables
、commonAnnotation
他们可以修改一些默认的字段,如果用户想要添加或减少能被 commonLabel
所修改的字段,则不是很容易做到;而使用 transformers
的话,用户可以指定哪些字段能被修改,而不受默认值的影响。
AnnotationTransformer
使用 kustomization.yaml
字段名称:commonAnnotations
为所有资源添加注释,和标签一样以 key: value 的形式。
commonAnnotations:
oncallPager: 800-555-1212
使用插件
Arguments
Annotations map[string]string
FieldSpecs []config.FieldSpec
Example
apiVersion: builtin kind: AnnotationsTransformer metadata: name: not-important-to-example annotations: app: myApp greeting/morning: a string with blanks fieldSpecs: - path: metadata/annotations create: true
ConfigMapGenerator
使用 kustomization.yaml
字段名称:configMapGenerator
列表中的每个条目都将生成一个 ConfigMap (合计可以生成 n 个 ConfigMap)。
下面的示例会生成 3 个ConfigMap:第一个带有给定文件的名称和内容,第二个将在 data 中添加 key/value,第三个通过 options
为单个 ConfigMap 设置注释和标签。
每个 configMapGenerator 项均接受的参数 behavior: [create|replace|merge]
,这个参数允许修改或替换父级现有的 configMap。
此外,每个条目都有一个 options
字段,该字段具有与 kustomization 文件的 generatorOptions
字段相同的子字段。
options
字段允许用户为生成的实例添加标签和(或)注释,或者分别禁用该实例名称的哈希后缀。此处添加的标签和注释不会被 kustomization 文件 generatorOptions
字段关联的全局选项覆盖。但是如果全局 generatorOptions
字段指定 disableNameSuffixHash: true
,其他 options
的设置将无法将其覆盖。
# These labels are added to all configmaps and secrets.
generatorOptions:
labels:
fruit: apple
configMapGenerator:
- name: my-java-server-props
behavior: merge
files:
- application.properties
- more.properties
- name: my-java-server-env-vars
literals:
- JAVA_HOME=/opt/java/jdk
- JAVA_TOOL_OPTIONS=-agentlib:hprof
options:
disableNameSuffixHash: true
labels:
pet: dog
- name: dashboards
files:
- mydashboard.json
options:
annotations:
dashboard: "1"
labels:
app.kubernetes.io/name: "app1"
这里也可以定义一个 key 来为文件设置不同名称。
下面这个示例会创建一个 ConfigMap,并将 whatever.ini
重命名为 myFileName.ini
:
configMapGenerator:
- name: app-whatever
files:
- myFileName.ini=whatever.ini
使用插件
Arguments
Example
apiVersion: builtin kind: ConfigMapGenerator metadata: name: mymap envs: - devops.env - uxteam.env literals: - FRUIT=apple - VEGETABLE=carrot
ImageTagTransformer
使用 kustomization.yaml
字段名称:images
修改镜像的名称、tag 或 image digest ,而无需使用 patches 。例如,对于这种 kubernetes Deployment 片段:
containers:
- name: mypostgresdb
image: postgres:8
- name: nginxapp
image: nginx:1.7.9
- name: myapp
image: my-demo-app:latest
- name: alpine-app
image: alpine:3.7
想要将 image
做如下更改:
- 将
postgres:8
改为my-registry/my-postgres:v1
- 将 nginx tag 从
1.7.9
改为1.8.0
- 将镜像名称
my-demo-app
改为my-app
- 将 alpine 的 tag
3.7
改为 digest 值
只需在 kustomization 中添加以下内容:
images:
- name: postgres
newName: my-registry/my-postgres
newTag: v1
- name: nginx
newTag: 1.8.0
- name: my-demo-app
newName: my-app
- name: alpine
digest: sha256:24a0c4b4a4c0eb97a1aabb8e29f18e917d05abfe1b7a7c07857230879ce7d3d3
使用插件
Arguments
ImageTag image.Image
FieldSpecs []config.FieldSpec
Example
apiVersion: builtin kind: ImageTagTransformer metadata: name: not-important-to-example imageTag: name: nginx newTag: v2
LabelTransformer
使用 kustomization.yaml
字段名称:commonLabels
为所有资源和 selectors 增加标签。
commonLabels:
someName: someValue
owner: alice
app: bingo
使用插件
Arguments
Labels map[string]string
FieldSpecs []config.FieldSpec
Example
apiVersion: builtin kind: LabelTransformer metadata: name: not-important-to-example labels: app: myApp env: production fieldSpecs: - path: metadata/labels create: true
NamespaceTransformer
使用 kustomization.yaml
字段名称:namespace
为所有资源添加 namespace。
namespace: my-namespace
使用插件
Arguments
FieldSpecs []config.FieldSpec
Example
apiVersion: builtin kind: NamespaceTransformer metadata: name: not-important-to-example namespace: test fieldSpecs: - path: metadata/namespace create: true - path: subjects kind: RoleBinding group: rbac.authorization.k8s.io - path: subjects kind: ClusterRoleBinding group: rbac.authorization.k8s.io
PatchesJson6902
使用 kustomization.yaml
字段名称:patchesJson6902
patchesJson6902 列表中的每个条目都应可以解析为 kubernetes 对象和将应用于该对象的 JSON patch。
目标字段指向的 kubernetes 对象的 group、 version、 kind、 name 和 namespace 在同一 kustomization 内 path 字段内容是 JSON patch 文件的相对路径。
patch 文件中的内容可以如下这种 JSON 格式:
[
{"op": "add", "path": "/some/new/path", "value": "value"},
{"op": "replace", "path": "/some/existing/path", "value": "new value"}
]
也可以使用 YAML 格式表示:
- op: add
path: /some/new/path
value: value
- op: replace
path: /some/existing/path
value: new value
patchesJson6902:
- target:
version: v1
kind: Deployment
name: my-deployment
path: add_init_container.yaml
- target:
version: v1
kind: Service
name: my-service
path: add_service_annotation.yaml
patch 内容也可以是一个inline string:
patchesJson6902:
- target:
version: v1
kind: Deployment
name: my-deployment
patch: |-
- op: add
path: /some/new/path
value: value
- op: replace
path: /some/existing/path
value: "new value"
使用插件
Arguments
Target types.PatchTarget
Path string
JsonOp string
Example
apiVersion: builtin kind: PatchJson6902Transformer metadata: name: not-important-to-example target: group: apps version: v1 kind: Deployment name: my-deploy path: jsonpatch.json
PatchesStrategicMerge
使用 kustomization.yaml
字段名称:patchesStrategicMerge
此列表中的每个条目都应可以解析为 StrategicMergePatch.
这些(也可能是部分的)资源文件中的 name 必须与已经通过 resources
加载的 name 字段匹配,或者通过 bases
中的 name 字段匹配。这些条目将用于 patch(修改)已知资源。
推荐使用小的 patches,例如:修改内存的 request/limit,更改 ConfigMap 中的 env 变量等。小的 patches 易于维护和查看,并且易于在 overlays 中混合使用。
patchesStrategicMerge:
- service_port_8888.yaml
- deployment_increase_replicas.yaml
- deployment_increase_memory.yaml
patch 内容也可以是一个inline string:
patchesStrategicMerge:
- |-
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
template:
spec:
containers:
- name: nginx
image: nignx:latest
请注意,kustomize 不支持同一个 patch 对象中包含多个 删除 指令。要从一个对象中删除多个字段或切片元素,需要创建一个单独的 patch,以执行所有需要的删除。
使用插件
Arguments
Paths []types.PatchStrategicMerge
Patches string
Example
apiVersion: builtin kind: PatchStrategicMergeTransformer metadata: name: not-important-to-example paths: - patch.yaml
PatchTransformer
使用 kustomization.yaml
字段名称:patches
这个列表中的每个条目应该解析到一个 Patch 对象,其中包括一个 patch 和一个目标选择器。patch 可以是 Strategic Merge Patch 或 JSON patch,也可以是 patch 文件或 inline string。目标选择器可以通过 group、version、kind、name、namespace、标签选择器和注释选择器来选择资源,选择一个或多个匹配所有指定字段的资源来应用 patch。
patches:
- path: patch.yaml
target:
group: apps
version: v1
kind: Deployment
name: deploy.*
labelSelector: "env=dev"
annotationSelector: "zone=west"
- patch: |-
- op: replace
path: /some/existing/path
value: new value
target:
kind: MyKind
labelSelector: "env=dev"
The name
and namespace
fields of the patch target selector are
automatically anchored regular expressions. This means that the value myapp
is equivalent to ^myapp$
。
使用插件
Arguments
Path string
Patch string
Target *types.Selector
Example
apiVersion: builtin kind: PatchTransformer metadata: name: not-important-to-example patch: '[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value": "nginx:latest"}]' target: name: .*Deploy kind: Deployment
PrefixSuffixTransformer
使用 kustomization.yaml
字段名称:namePrefix
, nameSuffix
为所有资源的名称添加前缀或后缀。
例如:将 deployment 名称从 wordpress
变为 alices-wordpress
或 wordpress-v2
或 alices-wordpress-v2
。
namePrefix: alices-
nameSuffix: -v2
如果资源类型是 ConfigMap 或 Secret,则在哈希值之前添加后缀。
使用插件
Arguments
Prefix string
Suffix string
FieldSpecs []config.FieldSpec
Example
apiVersion: builtin kind: PrefixSuffixTransformer metadata: name: not-important-to-example prefix: baked- suffix: -pie fieldSpecs: - path: metadata/name
ReplicaCountTransformer
使用 kustomization.yaml
字段名称:replicas
修改资源的副本数。
例如:对于如下 kubernetes Deployment 片段:
kind: Deployment
metadata:
name: deployment-name
spec:
replicas: 3
在 kustomization 中添加以下内容,将副本数更改为 5:
replicas:
- name: deployment-name
count: 5
该字段内容为列表,所以可以同时修改许多资源。
由于这个声明无法设置 kind:
或 group:
,所以他只能匹配如下资源中的一种:
Deployment
ReplicationController
ReplicaSet
StatefulSet
对于更复杂的用例,请使用 patch 。
使用插件
Arguments
Replica types.Replica
FieldSpecs []config.FieldSpec
Example
apiVersion: builtin kind: ReplicaCountTransformer metadata: name: not-important-to-example replica: name: myapp count: 23 fieldSpecs: - path: spec/replicas create: true kind: Deployment - path: spec/replicas create: true kind: ReplicationController
SecretGenerator
使用 kustomization.yaml
字段名称:secretGenerator
列表中的每个条目都将生成一个 Secret(合计可以生成 n 个 Secrets)。
功能与之前描述的 configMapGenerator
字段类似。
secretGenerator:
- name: app-tls
files:
- secret/tls.cert
- secret/tls.key
type: "kubernetes.io/tls"
- name: app-tls-namespaced
# you can define a namespace to generate
# a secret in, defaults to: "default"
namespace: apps
files:
- tls.crt=catsecret/tls.cert
- tls.key=secret/tls.key
type: "kubernetes.io/tls"
- name: env_file_secret
envs:
- env.txt
type: Opaque
- name: secret-with-annotation
files:
- app-config.yaml
type: Opaque
options:
annotations:
app_config: "true"
labels:
app.kubernetes.io/name: "app2"
使用插件
Arguments
Example
apiVersion: builtin kind: SecretGenerator metadata: name: my-secret namespace: whatever behavior: merge envs: - a.env - b.env files: - obscure=longsecret.txt literals: - FRUIT=apple - VEGETABLE=carrot