Merge pull request #20661 from fancc/secret

fix some document format errors

Author: k8s-ci-robot

content/zh/docs/concepts/configuration/secret.md

@@ -73,9 +73,9 @@ See the [Service Account](/docs/tasks/configure-pod-container/configure-service-
 information on how Service Accounts work.
 -->
 
-如果需要，可以禁用或覆盖自动创建和使用API凭据。但是，如果您需要的只是安全地访问 apiserver，我们推荐这样的工作流程。
+如果需要，可以禁用或覆盖自动创建和使用 API 凭据。但是，如果您需要的只是安全地访问 apiserver，我们推荐这样的工作流程。
 
-参阅  [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) 文档获取关于 Service Account 如何工作的更多信息。
+参阅 [Service Account](/docs/tasks/configure-pod-container/configure-service-account/) 文档获取关于 Service Account 如何工作的更多信息。
 
 <!--
 ### Creating your own Secrets
@@ -169,7 +169,7 @@ or from being stored in a terminal log.
 
 {{< /note >}}
 
-默认情况下，`kubectl get`和`kubectl describe`避免显示密码的内容。 这是为了防止机密被意外地暴露给旁观者或存储在终端日志中。
+默认情况下，`kubectl get` 和 `kubectl describe` 避免显示密码的内容。 这是为了防止机密被意外地暴露给旁观者或存储在终端日志中。
 
 <!--
 See [decoding a secret](#decoding-a-secret) for how to see the contents of a secret.
@@ -191,8 +191,8 @@ secret data as unencoded strings.
 #### 手动创建 Secret
 
 您也可以先以 json 或 yaml 格式在文件中创建一个 secret 对象，然后创建该对象。
-[密码](/docs/reference/generated/kubernetes-api/v1.12/#secret-v1-core)包含两中类型，数据和字符串数据。
-数据字段用于存储使用base64编码的任意数据。 提供stringData字段是为了方便起见，它允许您将机密数据作为未编码的字符串提供。
+[密码](/docs/reference/generated/kubernetes-api/v1.12/#secret-v1-core)包含两种类型，数据和字符串数据。
+数据字段用于存储使用 base64 编码的任意数据。 提供 stringData 字段是为了方便起见，它允许您将机密数据作为未编码的字符串提供。
 
 <!--
 For example, to store two strings in a Secret using the data field, convert
@@ -250,7 +250,7 @@ parts of that configuration file during your deployment process.
 If your application uses the following configuration file:
 -->
 
-对于某些情况，您可能希望改用 stringData 字段。 此字段允许您将非 base64 编码的字符串直接放入 Secret 中，
+对于某些情况，您可能希望改用 stringData 字段。此字段允许您将非 base64 编码的字符串直接放入 Secret 中，
 并且在创建或更新 Secret 时将为您编码该字符串。
 
 下面的一个实践示例提供了一个参考，您正在部署使用密钥存储配置文件的应用程序，并希望在部署过程中填补齐配置文件的部分内容。
@@ -291,7 +291,7 @@ retrieving Secrets. For example, if you run the following command:
 -->
 
 然后，您的部署工具可以在执行 `kubectl apply` 之前替换模板的 `{{username}}` 和 `{{password}}` 变量。
-stringData 是只写的便利字段。 检索 Secrets 时永远不会被输出。 例如，如果您运行以下命令：
+stringData 是只写的便利字段。检索 Secrets 时永远不会被输出。例如，如果您运行以下命令：
 
 ```shell
 kubectl get secret mysecret -o yaml
@@ -322,7 +322,7 @@ If a field is specified in both data and stringData, the value from stringData
 is used. For example, the following Secret definition:
 -->
 
-如果在 data 和 stringData 中都指定了字段，则使用 stringData 中的值。 例如，以下是 Secret 定义：
+如果在 data 和 stringData 中都指定了字段，则使用 stringData 中的值。例如，以下是 Secret 定义：
 
 ```yaml
 apiVersion: v1
@@ -374,13 +374,9 @@ the option `-w 0` to `base64` commands or the pipeline `base64 | tr -d '\n'` if
 `-w` option is not available.
 -->
 
-data和stringData的键必须由字母数字字符 '-', '_' 或者 '.' 组成。
+data 和 stringData 的键必须由字母数字字符 '-', '_' 或者 '.' 组成。
 
-** 编码注意：** 秘密数据的序列化 JSON 和 YAML 值被编码为base64字符串。
-换行符在这些字符串中无效，因此必须省略。
-在 Darwin / macOS 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来分隔长行。
-相反，Linux用户 *应该* 在 `base64` 命令中添加选项 `-w 0`， 或者，如果`-w`选项不可用的情况下，
-执行 `base64 | tr -d '\n'`。
+** 编码注意：** 秘密数据的序列化 JSON 和 YAML 值被编码为 base64 字符串。换行符在这些字符串中无效，因此必须省略。在 Darwin/macOS 上使用 `base64` 实用程序时，用户应避免使用 `-b` 选项来分隔长行。相反，Linux用户 *应该* 在 `base64` 命令中添加选项 `-w 0` ，或者，如果 `-w` 选项不可用的情况下，执行 `base64 | tr -d '\n'`。
 
 <!--
 #### Creating a Secret from Generator
@@ -394,9 +390,9 @@ For example, to generate a Secret from files `./username.txt` and `./password.tx
 -->
 
 #### 从生成器创建 Secret
-Kubectl 从1.14版本开始支持 [使用 Kustomize 管理对象](/docs/tasks/manage-kubernetes-objects/kustomization/)
+Kubectl 从 1.14 版本开始支持 [使用 Kustomize 管理对象](/docs/tasks/manage-kubernetes-objects/kustomization/)
 使用此新功能，您还可以从生成器创建一个 Secret，然后将其应用于在 Apiserver 上创建对象。
-生成器应在目录内的“ kustomization.yaml”中指定。
+生成器应在目录内的 `kustomization.yaml` 中指定。
 
 例如，从文件 `./username.txt` 和 `./password.txt` 生成一个 Secret。
 
@@ -476,8 +472,7 @@ The generated Secrets name has a suffix appended by hashing the contents. This e
 Secret is generated each time the contents is modified.
 -->
 
-通过对内容进行序列化后，生成一个后缀作为 Secrets 的名称。
-这样可以确保每次修改内容时都会生成一个新的Secret。
+通过对内容进行序列化后，生成一个后缀作为 Secrets 的名称。这样可以确保每次修改内容时都会生成一个新的 Secret。
 
 {{< /note >}}
 
@@ -540,7 +535,7 @@ kubectl edit secrets mysecret
 This will open the default configured editor and allow for updating the base64 encoded secret values in the `data` field:
 -->
 
-这将打开默认配置的编辑器，并允许更新 `data` 字段中的base64编码的 secret：
+这将打开默认配置的编辑器，并允许更新 `data` 字段中的 base64 编码的 secret：
 
 ```
 # Please edit the object below. Lines beginning with a '#' will be ignored,
@@ -832,14 +827,12 @@ when new keys are projected to the Pod can be as long as kubelet sync period + c
 propagation delay, where cache propagation delay depends on the chosen cache type
 (it equals to watch propagation delay, ttl of cache, or zero corespondingly).
 -->
-当已经在 volume 中被消费的 secret 被更新时，被映射的 key 也将被更新。
-Kubelet 在周期性同步时检查被挂载的 secret 是不是最新的。
-但是，它正在使用其本地缓存来获取 Secret 的当前值。
+当已经在 volume 中被消费的 secret 被更新时，被映射的 key 也将被更新。Kubelet 在周期性同步时检查被挂载的 secret 是不是最新的。但是，它正在使用其本地缓存来获取 Secret 的当前值。
 
 缓存的类型可以使用 (`ConfigMapAndSecretChangeDetectionStrategy` 中的 [KubeletConfiguration 结构](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)).
 它可以通过基于 ttl 的 watch(默认)传播，也可以将所有请求直接重定向到直接kube-apiserver。
 结果，从更新密钥到将新密钥投射到 Pod 的那一刻的总延迟可能与 kubelet 同步周期 + 缓存传播延迟一样长，其中缓存传播延迟取决于所选的缓存类型。
-(它等于观察传播延迟，缓存的ttl或相应为0)
+(它等于观察传播延迟，缓存的 ttl 或相应为 0)
 
 {{< note >}}
 
@@ -877,8 +870,7 @@ To use this feature, enable the `ImmutableEmphemeralVolumes`
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set
 your Secret or ConfigMap `immutable` field to `true`. For example:
 -->
-使用这个特性需要启用 `ImmutableEmphemeralVolumes`
-[特性开关](/docs/reference/command-line-tools-reference/feature-gates/) 并将 Secret 或 ConfigMap 的 `immutable` 字段设置为 `true`. 例如：
+使用这个特性需要启用 `ImmutableEmphemeralVolumes` [特性开关](/docs/reference/command-line-tools-reference/feature-gates/) 并将 Secret 或 ConfigMap 的 `immutable` 字段设置为 `true`. 例如：
 
 ```yaml
 apiVersion: v1
@@ -1052,9 +1044,9 @@ controller.  It does not include pods created via the kubelets
 not common ways to create pods.)
 -->
 
-每个 secret 的大小限制为1MB。这是为了防止创建非常大的 secret 会耗尽 apiserver 和 kubelet 的内存。然而，创建许多较小的 secret 也可能耗尽内存。更全面得限制 secret 对内存使用的功能还在计划中。
+每个 secret 的大小限制为 1MB。这是为了防止创建非常大的 secret 会耗尽 apiserver 和 kubelet 的内存。然而，创建许多较小的 secret 也可能耗尽内存。更全面得限制 secret 对内存使用的功能还在计划中。
 
-Kubelet 仅支持从 API server 获取的 Pod 使用 secret。这包括使用 kubectl 创建的任何 pod，或间接通过 replication controller 创建的 pod。它不包括通过 kubelet `--manifest-url` 标志，其 `--config` 标志或其 REST API 创建的pod（这些不是创建 pod 的常用方法）。
+Kubelet 仅支持从 API server 获取的 Pod 使用 secret。这包括使用 kubectl 创建的任何 pod，或间接通过 replication controller 创建的 pod。它不包括通过 kubelet `--manifest-url` 标志，其 `--config` 标志或其 REST API 创建的 pod（这些不是创建 pod 的常用方法）。
 
 <!--
 Secrets must be created before they are consumed in pods as environment
@@ -1100,7 +1092,7 @@ start until all the pod's volumes are mounted.
 -->
 ### Secret 与 Pod 生命周期的联系
 
-通过 API 创建 Pod 时，不会检查应用的 secret 是否存在。一旦 Pod 被调度，kubelet 就会尝试获取该 secret 的值。如果获取不到该 secret，或者暂时无法与 API server 建立连接，kubelet 将会定期重试。Kubelet 将会报告关于 pod 的事件，并解释它无法启动的原因。一旦获取到 secret，kubelet将创建并装载一个包含它的卷。在所有 pod 的卷被挂载之前，都不会启动 pod 的容器。
+通过 API 创建 Pod 时，不会检查应用的 secret 是否存在。一旦 Pod 被调度，kubelet 就会尝试获取该 secret 的值。如果获取不到该 secret，或者暂时无法与 API server 建立连接，kubelet 将会定期重试。Kubelet 将会报告关于 pod 的事件，并解释它无法启动的原因。一旦获取到 secret，kubelet 将创建并装载一个包含它的卷。在所有 pod 的卷被挂载之前，都不会启动 pod 的容器。
 
 <!--
 ## Use cases
@@ -1137,7 +1129,7 @@ Think carefully before sending your own ssh keys: other users of the cluster may
 Now we can create a pod which references the secret with the ssh key and
 consumes it in a volume:
 -->
-现在我们可以创建一个使用 ssh 密钥引用 secret 的pod，并在一个卷中使用它：
+现在我们可以创建一个使用 ssh 密钥引用 secret 的 pod，并在一个卷中使用它：
 
 ```yaml
 apiVersion: v1
@@ -1451,7 +1443,7 @@ privileged, system-level components.
 
 Secret 中的值对于不同的环境来说重要性可能不同，例如对于 Kubernetes 集群内部（例如 service account 令牌）和集群外部来说就不一样。即使一个应用程序可以理解其期望的与之交互的 secret 有多大的能力，但是同一命名空间中的其他应用程序却可能不这样认为。
 
-由于这些原因，在命名空间中 `watch` 和 `list`  secret 的请求是非常强大的功能，应该避免这样的行为，因为列出 secret 可以让客户端检查所有 secret 是否在该命名空间中。在群集中`watch` 和 `list` 所有 secret 的能力应该只保留给最有特权的系统级组件。
+由于这些原因，在命名空间中 `watch` 和 `list`  secret 的请求是非常强大的功能，应该避免这样的行为，因为列出 secret 可以让客户端检查所有 secret 是否在该命名空间中。在群集中 `watch` 和 `list` 所有 secret 的能力应该只保留给最有特权的系统级组件。
 
 <!--
 Applications that need to access the secrets API should perform `get` requests on