[zh-cn] resync kustomization.md

Author: windsonsea

content/zh-cn/docs/tasks/manage-kubernetes-objects/kustomization.md

@@ -34,7 +34,7 @@ kubectl kustomize <kustomization_directory>
 <!--
 To apply those Resources, run `kubectl apply` with `- -kustomize` or `-k` flag:
 -->
-要应用这些资源，使用参数 `--kustomize` 或 `-k` 标志来执行 `kubectl apply`：
+要应用这些资源，使用 `--kustomize` 或 `-k` 参数来执行 `kubectl apply`：
 
 ```shell
 kubectl apply -k <kustomization_directory>
@@ -45,7 +45,7 @@ kubectl apply -k <kustomization_directory>
 <!--
 Install [`kubectl`](/docs/tasks/tools/).
 -->
-安装 [`kubectl`](/zh-cn/docs/tasks/tools/).
+安装 [`kubectl`](/zh-cn/docs/tasks/tools/)。
 
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
@@ -62,8 +62,7 @@ Kustomize is a tool for customizing Kubernetes configurations. It has the follow
 -->
 ## Kustomize 概述    {#overview-of-kustomize}
 
-Kustomize 是一个用来定制 Kubernetes 配置的工具。它提供以下功能特性来管理
-应用配置文件：
+Kustomize 是一个用来定制 Kubernetes 配置的工具。它提供以下功能特性来管理应用配置文件：
 
 * 从其他来源生成资源
 * 为资源设置贯穿性（Cross-Cutting）字段
@@ -78,10 +77,8 @@ Kustomize has `secretGenerator` and `configMapGenerator`, which generate Secret
 ### 生成资源   {#generating-resources}
 
 ConfigMap 和 Secret 包含其他 Kubernetes 对象（如 Pod）所需要的配置或敏感数据。
-ConfigMap 或 Secret 中数据的来源往往是集群外部，例如某个 `.properties`
-文件或者 SSH 密钥文件。
-Kustomize 提供 `secretGenerator` 和 `configMapGenerator`，可以基于文件或字面
-值来生成 Secret 和 ConfigMap。
+ConfigMap 或 Secret 中数据的来源往往是集群外部，例如某个 `.properties` 文件或者 SSH 密钥文件。
+Kustomize 提供 `secretGenerator` 和 `configMapGenerator`，可以基于文件或字面值来生成 Secret 和 ConfigMap。
 
 <!--
 #### configMapGenerator
@@ -133,28 +130,16 @@ metadata:
 ```
 
 <!--
-To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`. This can also be used to set values from local environment variables by omitting the `=` and the value.
--->
-要从 env 文件生成 ConfigMap，请在 `configMapGenerator` 中的 `envs` 列表中添加一个条目。
-这也可以用于通过省略 `=` 和值来设置本地环境变量的值。
-
-<!--
-It's recommended to use the local environment variable population functionality sparingly - an overlay with a patch is often more maintainable. Setting values from the environment may be useful when they cannot easily be predicted, such as a git SHA.
--->
-建议谨慎使用本地环境变量填充功能 —— 用补丁覆盖通常更易于维护。 
-当无法轻松预测变量的值时，从环境中设置值可能很有用，例如 git SHA。
-
-<!--
+To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`.
 Here is an example of generating a ConfigMap with a data item from a `.env` file:
 -->
+要从 env 文件生成 ConfigMap，请在 `configMapGenerator` 中的 `envs` 列表中添加一个条目。
 下面是一个用来自 `.env` 文件的数据生成 ConfigMap 的例子：
 
 ```shell
 # 创建一个 .env 文件
-# BAZ 将使用本地环境变量 $BAZ 的取值填充
 cat <<EOF >.env
 FOO=Bar
-BAZ
 EOF
 
 cat <<EOF >./kustomization.yaml
@@ -171,7 +156,7 @@ The generated ConfigMap can be examined with the following command:
 可以使用以下命令检查生成的 ConfigMap：
 
 ```shell
-BAZ=Qux kubectl kustomize ./
+kubectl kustomize ./
 ```
 
 <!--
@@ -182,11 +167,10 @@ The generated ConfigMap is:
 ```yaml
 apiVersion: v1
 data:
-  BAZ: Qux
   FOO: Bar
 kind: ConfigMap
 metadata:
-  name: example-configmap-1-892ghb99c8
+  name: example-configmap-1-42cfbf598f
 ```
 
 <!--
@@ -201,8 +185,8 @@ Each variable in the `.env` file becomes a separate key in the ConfigMap that yo
 ConfigMaps can also be generated from literal key-value pairs. To generate a ConfigMap from a literal key-value pair, add an entry to the `literals` list in configMapGenerator. Here is an example of generating a ConfigMap with a data item from a key-value pair:
 -->
 ConfigMap 也可基于字面的键值偶对来生成。要基于键值偶对来生成 ConfigMap，
-在 `configMapGenerator` 的 `literals` 列表中添加表项。下面是一个例子，展示
-如何使用键值偶对中的数据条目来生成 ConfigMap 对象：
+在 `configMapGenerator` 的 `literals` 列表中添加表项。下面是一个例子，
+展示如何使用键值偶对中的数据条目来生成 ConfigMap 对象：
 
 ```shell
 cat <<EOF >./kustomization.yaml
@@ -414,7 +398,7 @@ type: Opaque
 <!--
 Like ConfigMaps, generated Secrets can be used in Deployments by referring to the name of the secretGenerator:
 -->
-与 ConfigMaps 一样，生成的 Secrets 可以通过引用 secretGenerator 的名称在部署中使用：
+与 ConfigMap 一样，生成的 Secret 可以通过引用 secretGenerator 的名称在 Deployment 中使用：
 
 ```shell
 # 创建一个 password.txt 文件
@@ -616,10 +600,9 @@ Here is an example of an NGINX application comprised of a Deployment and a Servi
 -->
 #### 组织    {#composing}
 
-Kustomize 支持组合不同的资源。`kustomization.yaml` 文件的 `resources` 字段
-定义配置中要包含的资源列表。你可以将 `resources` 列表中的路径设置为资源配置文件
-的路径。下面是由 Deployment 和 Service 构成的 NGINX 应用的示例：
-
+Kustomize 支持组合不同的资源。`kustomization.yaml` 文件的 `resources` 字段定义配置中要包含的资源列表。
+你可以将 `resources` 列表中的路径设置为资源配置文件的路径。
+下面是由 Deployment 和 Service 构成的 NGINX 应用的示例：
 
 ```shell
 # 创建 deployment.yaml 文件
@@ -683,13 +666,12 @@ mechanisms through `patchesStrategicMerge` and `patchesJson6902`. `patchesStrate
 #### 定制   {#customizing}
 
 补丁文件（Patches）可以用来对资源执行不同的定制。
-Kustomize 通过 `patchesStrategicMerge` 和 `patchesJson6902` 支持不同的打补丁
-机制。`patchesStrategicMerge` 的内容是一个文件路径的列表，其中每个文件都应可解析为
+Kustomize 通过 `patchesStrategicMerge` 和 `patchesJson6902` 支持不同的打补丁机制。
+`patchesStrategicMerge` 的内容是一个文件路径的列表，其中每个文件都应可解析为
 [策略性合并补丁（Strategic Merge Patch）](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md)。
 补丁文件中的名称必须与已经加载的资源的名称匹配。
 建议构造规模较小的、仅做一件事情的补丁。
-例如，构造一个补丁来增加 Deployment
-的副本个数；构造另外一个补丁来设置内存限制。
+例如，构造一个补丁来增加 Deployment 的副本个数；构造另外一个补丁来设置内存限制。
 
 ```shell
 # 创建 deployment.yaml 文件
@@ -788,11 +770,10 @@ specified in `kustomization.yaml`. For example, increasing the replica number of
 through `patchesJson6902`.
 -->
 并非所有资源或者字段都支持策略性合并补丁。为了支持对任何资源的任何字段进行修改，
-Kustomize 提供通过 `patchesJson6902` 来应用 [JSON 补丁](https://tools.ietf.org/html/rfc6902)
-的能力。为了给 JSON 补丁找到正确的资源，需要在 `kustomization.yaml` 文件中指定资源的
-组（group）、版本（version）、类别（kind）和名称（name）。
-例如，为某 Deployment 对象增加副本个数的操作也可以通过 `patchesJson6902`
-来完成：
+Kustomize 提供通过 `patchesJson6902` 来应用 [JSON 补丁](https://tools.ietf.org/html/rfc6902)的能力。
+为了给 JSON 补丁找到正确的资源，需要在 `kustomization.yaml` 文件中指定资源的组（group）、
+版本（version）、类别（kind）和名称（name）。
+例如，为某 Deployment 对象增加副本个数的操作也可以通过 `patchesJson6902` 来完成：
 
 ```shell
 # 创建一个 deployment.yaml 文件
@@ -871,10 +852,8 @@ spec:
 In addition to patches, Kustomize also offers customizing container images or injecting field values from other objects into containers
 without creating patches. For example, you can change the image used inside containers by specifying the new image in `images` field in `kustomization.yaml`.
 -->
-除了补丁之外，Kustomize 还提供定制容器镜像或者将其他对象的字段值注入到容器
-中的能力，并且不需要创建补丁。
-例如，你可以通过在 `kustomization.yaml` 文件的 `images` 字段设置新的镜像来
-更改容器中使用的镜像。
+除了补丁之外，Kustomize 还提供定制容器镜像或者将其他对象的字段值注入到容器中的能力，并且不需要创建补丁。
+例如，你可以通过在 `kustomization.yaml` 文件的 `images` 字段设置新的镜像来更改容器中使用的镜像。
 
 ```shell
 cat <<EOF > deployment.yaml
@@ -1108,8 +1087,8 @@ EOF
 This base can be used in multiple overlays. You can add different `namePrefix` or other cross-cutting fields
 in different overlays. Here are two overlays using the same base.
 -->
-此基准可在多个覆盖中使用。你可以在不同的覆盖中添加不同的 `namePrefix` 或
-其他贯穿性字段。下面是两个使用同一基准的覆盖：
+此基准可在多个覆盖中使用。你可以在不同的覆盖中添加不同的 `namePrefix` 或其他贯穿性字段。
+下面是两个使用同一基准的覆盖：
 
 ```shell
 mkdir dev
@@ -1145,7 +1124,7 @@ kubectl apply -k <kustomization 目录>/
 <!--
 Given the following `kustomization.yaml`,
 -->
-假定使用下面的 `kustomization.yaml`，
+假定使用下面的 `kustomization.yaml`：
 
 ```shell
 # 创建 deployment.yaml 文件
@@ -1209,8 +1188,7 @@ kubectl describe -k ./
 <!--
 Run the following command to compare the Deployment object `dev-my-nginx` against the state that the cluster would be in if the manifest was applied:
 -->
-执行下面的命令来比较 Deployment 对象 `dev-my-nginx` 与清单被应用之后
-集群将处于的状态：
+执行下面的命令来比较 Deployment 对象 `dev-my-nginx` 与清单被应用之后集群将处于的状态：
 
 ```shell
 kubectl diff -k ./
@@ -1231,7 +1209,7 @@ deployment.apps "dev-my-nginx" deleted
 <!--
 ## Kustomize Feature List
 -->
-## Kustomize 功能特性列表
+## Kustomize 功能特性列表 {#kustomize-feature-list}
 
 <!--
 | Field                 | Type                                                                                                         | Explanation                                                                        |