kubernetes-sigs/kustomize
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/kustomize.git synced 2026-06-13 01:50:55 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

Merge pull request #861 from kbhawkey/fix-spelling-transformerconfig

Browse Source 
correct spelling, minor word ordering
This commit is contained in:
Kubernetes Prow Robot
2019-03-17 06:38:55 -07:00
committed by GitHub
parent d5d5c076a7 f850ca63f4
commit 2c9e4507a7
1 changed files with 43 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

75
examples/transformerconfigs/README.md
View File

@@ -1,37 +1,46 @@
# Transformer Configurations
Kustomize computes the resources by applying a series of transformers:
- namespace transformer
- prefix/suffix transformer
- label transformer
- annotation transformer
- name reference transformer
- variable reference transformer
Kustomize creates new resources by applying a series of transformations to an original
set of resources. Kustomize provides the following default transformers:
Each transformer takes a list of resources and modifies certain fields. The modification is based on the transformer's rule.
The fields to update is the transformer's configuration, which is a list of filedspec that can be represented in YAML format.
- namespace
- prefix/suffix
- label
- annotation
- name reference
- variable reference
## fieldSpec
FieldSpec is a type to represent a path to a field in one kind of resources. It has following format
```
A `fieldSpec` list, in a transformer's configuration, determines which resource types and which fields
within those types the transformer can modify.
## FieldSpec
FieldSpec is a type that represents a path to a field in one kind of resource.
```yaml
group: some-group
version: some-version
kind: some-kind
path: path/to/the/field
create: false
```
If `create` is set to true, it indicates the transformer to create the path if it is not found in the resources. This is most useful for label and annotation transformers, where the path for labels or annotations may not be set before the transformation.
## prefix/suffix transformer
Name prefix suffix transformer adds prefix and suffix to the `metadata/name` field for all resources with following configuration:
```
If `create` is set to `true`, the transformer creates the path to the field in the resource if the path is not already found. This is most useful for label and annotation transformers, where the path for labels or annotations may not be set before the transformation.
## Prefix/suffix transformer
The prefix/suffix transformer adds a prefix/suffix to the `metadata/name` field for all resources. Here is the default prefix transformer configuration:
```yaml
namePrefix:
- path: metadata/name
```
## label transformer
Label transformer adds labels to `metadata/labels` field for all resources. It also adds labels to `spec/selector` field in all Service and to `spec/selector/matchLabels` field in all Deployment.
```
## Label transformer
The label transformer adds labels to the `metadata/labels` field for all resources. It also adds labels to the `spec/selector` field in all Service resources as well as the `spec/selector/matchLabels` field in all Deployment resources.
```yaml
commonLabels:
- path: metadata/labels
create: true
@@ -44,15 +53,16 @@ commonLabels:
- path: spec/selector/matchLabels
create: true
kind: Deployment
(etc.)
```
## name reference transformer
Name reference transformer's configuration is different from all other transformers. It contains a list of namebackreferences, which represented all the possible fields that a type could be used as a reference in other types of resources. A namebackreference contains a type such as ConfigMap as well as a list of FieldSpecs where ConfigMap is referenced. Here is an example.
```
## Name reference transformer
Name reference transformer's configuration is different from all other transformers. It contains a list of `nameReferences`, which represent all of the possible fields that a type could be used as a reference in other types of resources. A `nameReference` contains a type such as ConfigMap as well as a list of `fieldSpecs` where ConfigMap is referenced in other resources. Here is an example:
```yaml
kind: ConfigMap
version: v1
FieldSpecs:
fieldSpecs:
- kind: Pod
version: v1
path: spec/volumes/configMap/name
@@ -60,10 +70,11 @@ FieldSpecs:
path: spec/template/spec/volumes/configMap/name
- kind: Job
path: spec/template/spec/volumes/configMap/name
(etc.)
```
Name reference transformer configuration contains a list of such namebackreferences for ConfigMap, Secret, Service, Role, ServiceAccount and so on.
```
Name reference transformer's configuration contains a list of `nameReferences` for resources such as ConfigMap, Secret, Service, Role, and ServiceAccount. Here is an example configuration:
```yaml
nameReference:
- kind: ConfigMap
version: v1
@@ -74,7 +85,7 @@ nameReference:
- path: spec/containers/env/valueFrom/configMapKeyRef/name
version: v1
kind: Pod
(etc.)
# ...
- kind: Secret
version: v1
fieldSpecs:
@@ -84,12 +95,12 @@ nameReference:
- path: spec/containers/env/valueFrom/secretKeyRef/name
version: v1
kind: Pod
(etc.)
```
## customizing transformer configurations
## Customizing transformer configurations
Kustomize has a default set of transformer configurations. You can save the default transformer configurations to a local directory by calling `kustomize config save -d`, and modify and use these configurations. Kustomize also supports adding new transformer configurations to kustomization.yaml. This tutorial shows how to customize those configurations to:
Kustomize has a default set of configurations. They can be saved to local directory through `kustomize config save -d`. Kustomize allows modifying those configuration files and using them in kustomization.yaml file. This tutorial shows how to customize those configurations to
- [support a CRD type](crd/README.md)
- add extra fields for variable substitution
- add extra fields for name reference
- add extra fields for name reference