kubernetes-sigs/kustomize
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/kustomize.git synced 2026-05-17 18:25:26 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

Merge pull request #2046 from sunny0826/master

Browse Source 
Add multiple zh docs
This commit is contained in:
Kubernetes Prow Robot
2020-01-15 10:44:09 -08:00
committed by GitHub
parent 37ee56fc9a af27ada685
commit 983ac2be31
7 changed files with 1084 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
examples/zh/README.md
View File

@@ -48,14 +48,14 @@ go get sigs.k8s.io/kustomize/v3/cmd/kustomize
* [hello world](helloWorld.md) - 部署多个不同配置的 Hello World 服务。 * [hello world](helloWorld.md) - 部署多个不同配置的 Hello World 服务。
* [LDAP](../ldap/README.md) - 部署多个配置不同的 LDAP 服务。 * [LDAP](ldap.md) - 部署多个配置不同的 LDAP 服务。
* [springboot](../springboot/README.md) - 从头开始创建一个 Spring Boot 项目的生产配置。 * [springboot](springboot.md) - 从头开始创建一个 Spring Boot 项目的生产配置。
* [mySql](../mySql/README.md) - 从头开始创建一个 MySQL 的生产配置。 * [mySql](mysql.md) - 从头开始创建一个 MySQL 的生产配置。
* [breakfast](../breakfast.md) - 给 Alice 和 Bob 定制一顿早餐 :) * [breakfast](breakfast.md) - 给 Alice 和 Bob 定制一顿早餐 :)
* [multibases](../multibases/README.md) - 使用相同的 base 生成三个 variants（dev，staging，production）。 * [multibases](multibases.md) - 使用相同的 base 生成三个 variants（dev，staging，production）。
>声明：部分文档可能稍微滞后于英文版本，同步工作持续进行中 >声明：部分文档可能稍微滞后于英文版本，同步工作持续进行中

118
examples/zh/breakfast.md Normal file
View File

@@ -0,0 +1,118 @@
[kubernetes API 对象样式]: https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#required-fields
[variant]: ../../docs/glossary.md#variant
# 示例：早餐配置
定义一个工作空间：
<!-- @makeWorkplace @testAgainstLatestRelease -->
```
DEMO_HOME=$(mktemp -d)
```
创建目录用于存放早餐的 base 配置：
<!-- @baseDir @testAgainstLatestRelease -->
```
mkdir -p $DEMO_HOME/breakfast/base
```
创建一个 `kustomization` 来定义早餐所需的食物。包含咖啡和薄煎饼：
<!-- @baseKustomization @testAgainstLatestRelease -->
```
cat <<EOF >$DEMO_HOME/breakfast/base/kustomization.yaml
resources:
- coffee.yaml
- pancakes.yaml
EOF
```
这里有一个 _coffee_ 类型。定义`kind`和 `metdata/name` 字段以符合 [kubernetes API 对象样式]，不需要其他文件或定义：
<!-- @coffee @testAgainstLatestRelease -->
```
cat <<EOF >$DEMO_HOME/breakfast/base/coffee.yaml
kind: Coffee
metadata:
name: morningCup
temperature: lukewarm
data:
greeting: "Good Morning!"
EOF
```
`name` 字段仅将这种咖啡实例与其他实例（如果有的话）区分开
同样，定义 _pancakes_：
<!-- @pancakes @testAgainstLatestRelease -->
```
cat <<EOF >$DEMO_HOME/breakfast/base/pancakes.yaml
kind: Pancakes
metadata:
name: comfort
stacksize: 3
topping: none
EOF
```
为喜欢热咖啡的 Alice 定制她的早餐：
<!-- @aliceOverlay @testAgainstLatestRelease -->
```
mkdir -p $DEMO_HOME/breakfast/overlays/alice
cat <<EOF >$DEMO_HOME/breakfast/overlays/alice/kustomization.yaml
commonLabels:
who: alice
resources:
- ../../base
patchesStrategicMerge:
- temperature.yaml
EOF
cat <<EOF >$DEMO_HOME/breakfast/overlays/alice/temperature.yaml
kind: Coffee
metadata:
name: morningCup
temperature: hot!
EOF
```
同样的，Bob 想要 _5_ 块薄煎饼和草莓：
<!-- @bobOverlay @testAgainstLatestRelease -->
```
mkdir -p $DEMO_HOME/breakfast/overlays/bob
cat <<EOF >$DEMO_HOME/breakfast/overlays/bob/kustomization.yaml
commonLabels:
who: bob
resources:
- ../../base
patchesStrategicMerge:
- topping.yaml
EOF
cat <<EOF >$DEMO_HOME/breakfast/overlays/bob/topping.yaml
kind: Pancakes
metadata:
name: comfort
stacksize: 5
topping: strawberries
EOF
```
现在，可以为 Alice 的早餐生成配置了：
<!-- @generateAlice @testAgainstLatestRelease -->
```
kustomize build $DEMO_HOME/breakfast/overlays/alice
```
同样的，也为 Bob 的早餐生成配置：
<!-- @generateBob @testAgainstLatestRelease -->
```
kustomize build $DEMO_HOME/breakfast/overlays/bob
```

269
examples/zh/ldap.md Normal file
View File

@@ -0,0 +1,269 @@
[base]: ../../docs/glossary.md#base
[gitops]: ../../docs/glossary.md#gitops
[kustomization]: ../../docs/glossary.md#kustomization
[overlay]: ../../docs/glossary.md#overlay
[overlays]: ../../docs/glossary.md#overlay
[variant]: ../../docs/glossary.md#variant
[variants]: ../../docs/glossary.md#variant
# 示例：LDAP 服务
步骤：
1. 拉取已经存在的 [base] 配置
2. 进行配置
3. 基于 [base] 创建2个不同的 [overlays] (_staging_ 和 _production_)
4. 运行 kustomize 或 kubectl 部署 staging 和 production
首先创建一个工作空间：
<!-- @makeWorkplace @testAgainstLatestRelease -->
```
DEMO_HOME=$(mktemp -d)
```
或者
> ```
> DEMO_HOME=~/ldap
> ```
## 创建 base
要使用 [overlays] 创建 [variant]，首先需要创建一个 [base]。
为了保证文档的精简，基础资源都在补充目录中，如果需要请下载它们：
<!-- @downloadBase @testAgainstLatestRelease -->
```
BASE=$DEMO_HOME/base
mkdir -p $BASE
CONTENT="https://raw.githubusercontent.com\
/kubernetes-sigs/kustomize\
/master/examples/ldap"
curl -s -o "$BASE/#1" "$CONTENT/base\
/{deployment.yaml,kustomization.yaml,service.yaml,env.startup.txt}"
```
检查这个目录：
<!-- @runTree @testAgainstLatestRelease -->
```
tree $DEMO_HOME
```
将会看到如下文件：
> ```
> /tmp/tmp.IyYQQlHaJP
> └── base
> ├── deployment.yaml
> ├── env.startup.txt
> ├── kustomization.yaml
> └── service.yaml
> ```
这些资源可以由 kubectl 立刻部署到集群上来实例化 _ldap_ 服务：
> ```
> kubectl apply -f $DEMO_HOME/base
> ```
注意 `kubectl -f` 只能识别 k8s 资源文件。
### The Base Kustomization
`base` 目录包含一个 [kustomization] 文件：
<!-- @showKustomization @testAgainstLatestRelease -->
```
more $BASE/kustomization.yaml
```
（可选）在 base 上运行 `kustomize`，并将结果打印到标准输出：
<!-- @buildBase @testAgainstLatestRelease -->
```
kustomize build $BASE
```
### Customize the base
为所有资源设置名称前缀：
<!-- @namePrefix @testAgainstLatestRelease -->
```
cd $BASE
kustomize edit set nameprefix "my-"
```
查看变化：
<!-- @checkNameprefix @testAgainstLatestRelease -->
```
kustomize build $BASE | grep -C 3 "my-"
```
## 创建 Overlays
创建 _staging_ 和 _production_ 的 [overlay]:
* 为 _Staging_ 新增一个 ConfigMap
* 为 _Production_ 添加持久化存储盘和更多的副本数
* 现实两个 [variants] 的不同之处
<!-- @overlayDirectories @testAgainstLatestRelease -->
```
OVERLAYS=$DEMO_HOME/overlays
mkdir -p $OVERLAYS/staging
mkdir -p $OVERLAYS/production
```
#### Staging Kustomization
下载 staging 配置
<!-- @downloadStagingKustomization @testAgainstLatestRelease -->
```
curl -s -o "$OVERLAYS/staging/#1" "$CONTENT/overlays/staging\
/{config.env,deployment.yaml,kustomization.yaml}"
```
在 staging 配置中增加一个 ConfigMap
> ```cat $OVERLAYS/staging/kustomization.yaml
> (...truncated)
> configMapGenerator:
> - name: env-config
> files:
> - config.env
> ```
和2个副本
> ```cat $OVERLAYS/staging/deployment.yaml
> apiVersion: apps/v1
> kind: Deployment
> metadata:
> name: ldap
> spec:
> replicas: 2
> ```
#### Production Kustomization
下载 production 配置
<!-- @downloadProductionKustomization @testAgainstLatestRelease -->
```
curl -s -o "$OVERLAYS/production/#1" "$CONTENT/overlays/production\
/{deployment.yaml,kustomization.yaml}"
```
在 production 的配置中增加为6副本和存储盘
> ```cat $OVERLAYS/production/deployment.yaml
> apiVersion: apps/v1
> kind: Deployment
> metadata:
> name: ldap
> spec:
> replicas: 6
> template:
> spec:
> volumes:
> - name: ldap-data
> emptyDir: null
> gcePersistentDisk:
> pdName: ldap-persistent-storage
> ```
## 比较 overlays
`DEMO_HOME` 现在包括：
* 一个 _base_ 目录：对拉取原始配置进行少量的定制
* 一个 _overlays_ 目录：其中包含在集群中创建不同的 _staging_ 和 _production_ [variants] 所需的 kustomizations 文件和 patche 文件
查看目录结构和差异：
<!-- @listFiles @testAgainstLatestRelease -->
```
tree $DEMO_HOME
```
将会得到类似的内容：
> ```
> /tmp/tmp.IyYQQlHaJP1
> ├── base
> │   ├── deployment.yaml
> │   ├── env.startup.txt
> │   ├── kustomization.yaml
> │   └── service.yaml
> └── overlays
> ├── production
> │   ├── deployment.yaml
> │   └── kustomization.yaml
> └── staging
> ├── config.env
> ├── deployment.yaml
> └── kustomization.yaml
> ```
直接对输出内容进行比较，以查看 _staging_ 和 _production_ 的不同之处：
<!-- @compareOutput -->
```
diff \
<(kustomize build $OVERLAYS/staging) \
<(kustomize build $OVERLAYS/production) |\
more
```
输出的差异内容
> ```diff
> (...truncated)
> < name: staging-my-ldap-configmap-kftftt474h
> ---
> > name: production-my-ldap-configmap-k27f7hkg4f
> 85c75
> < name: staging-my-ldap-service
> ---
> > name: production-my-ldap-service
> 97c87
> < name: staging-my-ldap
> ---
> > name: production-my-ldap
> 99c89
> < replicas: 2
> ---
> > replicas: 6
> (...truncated)
> ```
## 部署
查看各个资源集：
<!-- @buildStaging @testAgainstLatestRelease -->
```
kustomize build $OVERLAYS/staging
```
<!-- @buildProduction @testAgainstLatestRelease -->
```
kustomize build $OVERLAYS/production
```
将上述命令通过管道传递给 kubectl 以进行部署：
> ```
> kustomize build $OVERLAYS/staging |\
> kubectl apply -f -
> ```
> ```
> kustomize build $OVERLAYS/production |\
> kubectl apply -f -
> ```

113
examples/zh/multi-namespace.md Normal file
View File

@@ -0,0 +1,113 @@
# 示例：使用通用的 base 应用多 namespace
`kustomize` 支持基于同一base具有不同 namespace 的多个 variants。
只需将 overlay 作为新的 kustomization 的 base，就可以创建一个额外的 overlay 将这些 variants 组合在一起。下面使用一个 pod 作为 base 来进行演示。
创建一个工作空间：
<!-- @makeWorkplace @testAgainstLatestRelease -->
```
DEMO_HOME=$(mktemp -d)
```
定义一个通用的 base：
<!-- @makeBase @testAgainstLatestRelease -->
```
BASE=$DEMO_HOME/base
mkdir $BASE
cat <<EOF >$BASE/kustomization.yaml
resources:
- pod.yaml
EOF
cat <<EOF >$BASE/pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx:1.7.9
EOF
```
定义 namespace-a 的 variant：
<!-- @makeNamespaceA @testAgainstLatestRelease -->
```
NSA=$DEMO_HOME/namespace-a
mkdir $NSA
cat <<EOF >$NSA/kustomization.yaml
resources:
- namespace.yaml
- ../base
namespace: namespace-a
EOF
cat <<EOF >$NSA/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: namespace-a
EOF
```
定义 namespace-b 的 variant：
<!-- @makeNamespaceB @testAgainstLatestRelease -->
```
NSB=$DEMO_HOME/namespace-b
mkdir $NSB
cat <<EOF >$NSB/kustomization.yaml
resources:
- namespace.yaml
- ../base
namespace: namespace-b
EOF
cat <<EOF >$NSB/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: namespace-b
EOF
```
然后定义一个 _Kustomization_，将两个 variants 组合在一起：
<!-- @makeTopLayer @testAgainstLatestRelease -->
```
cat <<EOF >$DEMO_HOME/kustomization.yaml
resources:
- namespace-a
- namespace-b
EOF
```
现在工作空间有如下目录：
> ```
> .
> ├── base
> │   ├── kustomization.yaml
> │   └── pod.yaml
> ├── kustomization.yaml
> ├── namespace-a
> │   ├── kustomization.yaml
> │   └── namespace.yaml
> └── namespace-b
> ├── kustomization.yaml
> └── namespace.yaml
> ```
输出两个 namespace 的 pod 对象，分别在 namespace-a 和 namespace-b。
<!-- @confirmVariants @testAgainstLatestRelease -->
```
test 2 == \
$(kustomize build $DEMO_HOME| grep -B 4 "namespace: namespace-[ab]" | grep "name: myapp-pod" | wc -l); \
echo $?
```

127
examples/zh/multibases.md Normal file
View File

@@ -0,0 +1,127 @@
# 示例：多 Overlay 使用相同 base
`kustomize` 鼓励定义多个 variants：例如在通用的 base 上使用 dev、staging 和 prod overlay。
可以创建其他 overlay 来将这些 variants 组合在一起：只需将 overlay 声明为新 kustomization 的 base 即可。
如果 base 由于某种原因无法控制，将多个 variants 组合在一起也可以为他们添加通用的 label 或 annotation。
下面使用一个 pod 作为 base 来进行演示。
首先创建一个工作空间：
<!-- @makeWorkplace @testAgainstLatestRelease -->
```
DEMO_HOME=$(mktemp -d)
```
定义一个通用的 base：
<!-- @makeBase @testAgainstLatestRelease -->
```
BASE=$DEMO_HOME/base
mkdir $BASE
cat <<EOF >$BASE/kustomization.yaml
resources:
- pod.yaml
EOF
cat <<EOF >$BASE/pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: nginx
image: nginx:1.7.9
EOF
```
定义 dev variant：
<!-- @makeDev @testAgainstLatestRelease -->
```
DEV=$DEMO_HOME/dev
mkdir $DEV
cat <<EOF >$DEV/kustomization.yaml
resources:
- ./../base
namePrefix: dev-
EOF
```
定义 staging variant：
<!-- @makeStaging @testAgainstLatestRelease -->
```
STAG=$DEMO_HOME/staging
mkdir $STAG
cat <<EOF >$STAG/kustomization.yaml
resources:
- ./../base
namePrefix: stag-
EOF
```
定义 production variant：
<!-- @makeProd @testAgainstLatestRelease -->
```
PROD=$DEMO_HOME/production
mkdir $PROD
cat <<EOF >$PROD/kustomization.yaml
resources:
- ./../base
namePrefix: prod-
EOF
```
然后定义一个 _Kustomization_，将三个 variants 组合在一起：
<!-- @makeTopLayer @testAgainstLatestRelease -->
```
cat <<EOF >$DEMO_HOME/kustomization.yaml
resources:
- ./dev
- ./staging
- ./production
namePrefix: cluster-a-
EOF
```
现在工作空间有如下目录：
> ```
> .
> ├── base
> │   ├── kustomization.yaml
> │   └── pod.yaml
> ├── dev
> │   └── kustomization.yaml
> ├── kustomization.yaml
> ├── production
> │   └── kustomization.yaml
> └── staging
> └── kustomization.yaml
> ```
输出包含三个 pod 对象，分别来自 dev、staging 和 production variants。
<!-- @confirmVariants @testAgainstLatestRelease -->
```
test 1 == \
$(kustomize build $DEMO_HOME | grep cluster-a-dev-myapp-pod | wc -l); \
echo $?
test 1 == \
$(kustomize build $DEMO_HOME | grep cluster-a-stag-myapp-pod | wc -l); \
echo $?
test 1 == \
$(kustomize build $DEMO_HOME | grep cluster-a-prod-myapp-pod | wc -l); \
echo $?
```
与在不同的 variants 中添加不同的 `namePrefix` 类似，也可以添加不同的 `namespace` 并在一个 _kustomization_ 中组成这些 variants。更多的详细信息，请查看[multi-namespaces](multi-namespace.md)。

171
examples/zh/mysql.md Normal file
View File

@@ -0,0 +1,171 @@
# 示例：MySql
本示例采用现成的专为 MySql 设计的 k8s 资源，并对其进行定制使其适合生产环境。
在生产环境中，我们希望：
- 以 'prod-' 为前缀的 MySQL 资源
- MySQL 资源具有 'env: prod' label
- 使用持久化磁盘来存储 MySQL 数据
首先创建一个工作空间：
<!-- @makeDemoHome @testAgainstLatestRelease -->
```
DEMO_HOME=$(mktemp -d)
```
### 下载资源
为了保证文档的精简，基础资源都在补充目录中，如果需要请下载它们：
<!-- @downloadResources @testAgainstLatestRelease -->
```
curl -s -o "$DEMO_HOME/#1.yaml" "https://raw.githubusercontent.com\
/kubernetes-sigs/kustomize\
/master/examples/mySql\
/{deployment,secret,service}.yaml"
```
### 初始化 kustomization.yaml
`kustomize` 会从 `kustomization.yaml` 文件中获取指令，创建这个文件：
<!-- @kustomizeYaml @testAgainstLatestRelease -->
```
touch $DEMO_HOME/kustomization.yaml
```
### 添加资源
<!-- @addResources @testAgainstLatestRelease -->
```
cd $DEMO_HOME
kustomize edit add resource secret.yaml
kustomize edit add resource service.yaml
kustomize edit add resource deployment.yaml
cat kustomization.yaml
```
执行上面的命令后，`kustomization.yaml` 的 resources 字段如下：
> ```
> resources:
> - secret.yaml
> - service.yaml
> - deployment.yaml
> ```
### 定制名称
为 MySQL 资源添加 _prod-_ 前缀（这些资源将用于生产环境）：
<!-- @customizeLabel @testAgainstLatestRelease -->
```
cd $DEMO_HOME
kustomize edit set nameprefix 'prod-'
cat kustomization.yaml
```
执行上面的命令后，`kustomization.yaml` 的 namePrefix 字段将会被更新：
> ```
> namePrefix: prod-
> ```
`namePrefix` 将在所有资源的名称前添加 _prod-_ 的前缀，可以通过如下命令查看：
<!-- @genNamePrefixConfig @testAgainstLatestRelease -->
```
kustomize build $DEMO_HOME
```
输出内容：
> ```
> apiVersion: v1
> data:
> password: YWRtaW4=
> kind: Secret
> metadata:
> ....
> name: prod-mysql-pass-d2gtcm2t2k
> ---
> apiVersion: v1
> kind: Service
> metadata:
> ....
> name: prod-mysql
> spec:
> ....
> ---
> apiVersion: apps/v1
> kind: Deployment
> metadata:
> ....
> name: prod-mysql
> spec:
> selector:
> ....
> ```
### 定制 Label
我们希望生产环境的资源包含某些 Label，这样我们就可以通过 label selector 来查询到这些资源。
`kustomize` 没有 `edit set label` 命令来添加 label，但是可以通过编辑 `kustomization.yaml` 文件来实现：
<!-- @customizeLabels @testAgainstLatestRelease -->
```
sed -i.bak 's/app: helloworld/app: prod/' \
$DEMO_HOME/kustomization.yaml
```
这时，执行 `kustomize build` 命令将会生成包含 `prod-` 前缀和 `env:prod` label 的 MySQL 配置。
### 存储定制
现成的 MySQL 使用 `emptyDir` 类型的 volume，如果 MySQL Pod 被重新部署，则该类型的 volume 将会消失，这是不能应用于生产环境的，因此在生产环境中我们需要使用持久化磁盘。在 kustomize 中可以使用`patchesStrategicMerge` 来应用资源。
<!-- @createPatchFile @testAgainstLatestRelease -->
```
cat <<'EOF' > $DEMO_HOME/persistent-disk.yaml
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: mysql
spec:
template:
spec:
volumes:
- name: mysql-persistent-storage
emptyDir: null
gcePersistentDisk:
pdName: mysql-persistent-storage
EOF
```
将 patch 文件添加到 `kustomization.yaml` 中：
<!-- @specifyPatch @testAgainstLatestRelease -->
```
cat <<'EOF' >> $DEMO_HOME/kustomization.yaml
patchesStrategicMerge:
- persistent-disk.yaml
EOF
```
`mysql-persistent-storage` 必须存在一个持久化磁盘才能使其成功运行，分为两步：
1. 创建一个名为 `persistent-disk.yaml` 的 YAML 文件，用于修改 deployment.yaml 的定义。
2. 在 `kustomization.yaml` 中添加 `persistent-disk.yaml` 到 `patchesStrategicMerge` 列表中。运行 `kustomize build` 将 patch 应用于 Deployment 资源。
现在就可以将完整的配置输出并在集群中部署（将结果通过管道输出给 `kubectl apply`），在生产环境创建MySQL 应用。
<!-- @finalInflation @testAgainstLatestRelease -->
```
kustomize build $DEMO_HOME # | kubectl apply -f -
```

281
examples/zh/springboot.md Normal file
View File

@@ -0,0 +1,281 @@
# 示例：SpringBoot
在本教程中，您将学会如何使用 `kustomize` 定制一个运行 Spring Boot 应用的 k8s 配置。
在生产环境中，我们需要定制如下内容：
- 为 Spring Boot 应用添加特定配置
- 配置数据库连接
- 以 'prod-' 前缀命名资源
- 资源具有 'env: prod' label
- 设置合适的 JVM 内存
- 健康检查和就绪检查
首先创建一个工作空间：
<!-- @makeDemoHome @testAgainstLatestRelease -->
```
DEMO_HOME=$(mktemp -d)
```
### 下载资源
为了保证文档的精简，基础资源都在补充目录中，如果需要请下载它们：
<!-- @downloadResources @testAgainstLatestRelease -->
```
CONTENT="https://raw.githubusercontent.com\
/kubernetes-sigs/kustomize\
/master/examples/springboot"
curl -s -o "$DEMO_HOME/#1.yaml" \
"$CONTENT/base/{deployment,service}.yaml"
```
### 初始化 kustomization.yaml
`kustomize` 会从 `kustomization.yaml` 文件中获取指令，创建这个文件：
<!-- @kustomizeYaml @testAgainstLatestRelease -->
```
touch $DEMO_HOME/kustomization.yaml
```
### 添加资源
<!-- @addResources @testAgainstLatestRelease -->
```
cd $DEMO_HOME
kustomize edit add resource service.yaml
kustomize edit add resource deployment.yaml
cat kustomization.yaml
```
执行上面的命令后，`kustomization.yaml` 的 resources 字段如下：
> ```
> resources:
> - service.yaml
> - deployment.yaml
> ```
### 添加 configMap 生成器
<!-- @addConfigMap @testAgainstLatestRelease -->
```
echo "app.name=Kustomize Demo" >$DEMO_HOME/application.properties
kustomize edit add configmap demo-configmap \
--from-file application.properties
cat kustomization.yaml
```
执行上面的命令后，`kustomization.yaml` 的 configMapGenerator 字段如下：
> ```
> configMapGenerator:
> - files:
> - application.properties
> name: demo-configmap
> ```
### 定制 configMap
我们将为生产环境添加数据库连接凭证。通常这些凭据被存放在 `application.properties` 中，然而在有些时候，我们希望将这些凭证保存在其他文件中，而将应用的其他配置保存在 `application.properties` 中。通过这种清晰的分离，这些凭证和应用配置可由不同的团队管理和维护。例如，应用开发人员可以在 `application.properties` 中调整应用程序的配置，而数据库的连接凭证则由运维或 SRE 团队管理和维护。
对于 Spring Boot 应用，我们可以通过环境变量动态的设置 `spring.profiles.active`，然后应用将获取一个额外的 `application-<profile>.properties` 文件，我们可以分为两步定制这个 ConfigMap：
1. 通过 patch 添加一个环境变量
2. 将文件添加到 ConfigMap 中
<!-- @customizeConfigMap @testAgainstLatestRelease -->
```
cat <<EOF >$DEMO_HOME/patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: sbdemo
spec:
template:
spec:
containers:
- name: sbdemo
env:
- name: spring.profiles.active
value: prod
EOF
kustomize edit add patch patch.yaml
cat <<EOF >$DEMO_HOME/application-prod.properties
spring.jpa.hibernate.ddl-auto=update
spring.datasource.url=jdbc:mysql://<prod_database_host>:3306/db_example
spring.datasource.username=root
spring.datasource.password=admin
EOF
kustomize edit add configmap \
demo-configmap --from-file application-prod.properties
cat kustomization.yaml
```
执行上面的命令后，`kustomization.yaml` 的 configMapGenerator 字段如下：
> ```
> configMapGenerator:
> - files:
> - application.properties
> - application-prod.properties
> name: demo-configmap
> ```
### 定制名称
为资源添加 _prod-_ 前缀（这些资源将用于生产环境）：
<!-- @customizeLabel @testAgainstLatestRelease -->
```
cd $DEMO_HOME
kustomize edit set nameprefix 'prod-'
```
执行上面的命令后，`kustomization.yaml` 的 namePrefix 字段将会被更新：
> ```
> namePrefix: prod-
> ```
`namePrefix` 将在所有资源的名称前添加 _prod-_ 的前缀，可以通过如下命令查看：
<!-- @build1 @testAgainstLatestRelease -->
```
kustomize build $DEMO_HOME | grep prod-
```
### 定制 Label
我们希望生产环境的资源包含某些 Label，这样我们就可以通过 label selector 来查询到这些资源。
`kustomize` 没有 `edit set label` 命令来添加 label，但是可以通过编辑 `kustomization.yaml` 文件来实现：
<!-- @customizeLabels @testAgainstLatestRelease -->
```
cat <<EOF >>$DEMO_HOME/kustomization.yaml
commonLabels:
env: prod
EOF
```
现在所有资源都包含 `prod-` 前缀和 `env:prod` label，可以通过下面的命令来查看：
<!-- @build2 @testAgainstLatestRelease -->
```
kustomize build $DEMO_HOME | grep -C 3 env
```
### 下载调整 JVM 内存的 Patch
当 Spring Boot 应用部署在 k8s 集群中时，JVM 会运行在容器中。我们要为容器设置内存限制，并确保 JVM 知道容器的内存限制。在 k8s 的 Deployment 中，我们可以设置资源容器的资源限制，并将限制注入到一些环境变量中，当容器启动时，其可以获取环境变量并设置相应的 JVM 选项。
下载 `memorylimit_patch.yaml` 其包含内存限制设置的 patch：
<!-- @downloadPatch @testAgainstLatestRelease -->
```
curl -s -o "$DEMO_HOME/#1.yaml" \
"$CONTENT/overlays/production/{memorylimit_patch}.yaml"
cat $DEMO_HOME/memorylimit_patch.yaml
```
输出内容
> ```
> apiVersion: apps/v1
> kind: Deployment
> metadata:
> name: sbdemo
> spec:
> template:
> spec:
> containers:
> - name: sbdemo
> resources:
> limits:
> memory: 1250Mi
> requests:
> memory: 1250Mi
> env:
> - name: MEM_TOTAL_MB
> valueFrom:
> resourceFieldRef:
> resource: limits.memory
> ```
### 下载健康检查的 Patch
我们还可以在生产环境中添加健康检查和就绪检查，Spring Boot 应用都具有类似 `/actuator/health` 的接口用于健康检查，我们可以定制 k8s 的 Deployment 资源来进行健康检查和就绪检查。
下载 `memorylimit_patch.yaml` 其包含存活和就绪探针的 patch：
<!-- @downloadPatch @testAgainstLatestRelease -->
```
curl -s -o "$DEMO_HOME/#1.yaml" \
"$CONTENT/overlays/production/{healthcheck_patch}.yaml"
cat $DEMO_HOME/healthcheck_patch.yaml
```
输出内容
> ```
> apiVersion: apps/v1
> kind: Deployment
> metadata:
> name: sbdemo
> spec:
> template:
> spec:
> containers:
> - name: sbdemo
> livenessProbe:
> httpGet:
> path: /actuator/health
> port: 8080
> initialDelaySeconds: 10
> periodSeconds: 3
> readinessProbe:
> initialDelaySeconds: 20
> periodSeconds: 10
> httpGet:
> path: /actuator/info
> port: 8080
> ```
### 添加 patches
将这些 patch 添加到 `kustomization.yaml` 中：
<!-- @addPatch @testAgainstLatestRelease -->
```
cd $DEMO_HOME
kustomize edit add patch memorylimit_patch.yaml
kustomize edit add patch healthcheck_patch.yaml
```
执行上面的命令后，`kustomization.yaml` 的 patchesStrategicMerge 字段如下：
> ```
> patchesStrategicMerge:
> - patch.yaml
> - memorylimit_patch.yaml
> - healthcheck_patch.yaml
> ```
现在就可以将完整的配置输出并在集群中部署（将结果通过管道输出给 `kubectl apply`），在生产环境创建Spring Boot 应用。
<!-- @finalBuild @testAgainstLatestRelease -->
```
kustomize build $DEMO_HOME # | kubectl apply -f -
```