[zh] Clean PodPreset related pages/examples

Author: tengqm

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

@@ -45,6 +45,26 @@ Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象
 这样的信息可能会被放在 Pod 规约中或者镜像中。
 用户可以创建 Secret，同时系统也创建了一些 Secret。
 
+{{< caution >}}
+<!--
+Kubernetes Secrets are, by default, stored as unencrypted base64-encoded
+strings. By default they can be retrieved - as plain text - by anyone with API
+access, or anyone with access to Kubernetes' underlying data store, etcd. In
+order to safely use Secrets, we recommend you (at a minimum):
+
+1. [Enable Encryption at Rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) for Secrets.
+2. [Enable RBAC rules that restrict reading and writing the Secret](https://kubernetes.io/docs/reference/access-authn-authz/authorization/). Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod.
+-->
+Kubernetes Secret 默认情况下存储为 base64-编码的、非加密的字符串。
+默认情况下，能够访问 API 的任何人，或者能够访问 Kubernetes 下层数据存储（etcd）
+的任何人都可以以明文形式读取这些数据。
+为了能够安全地使用 Secret，我们建议你（至少）：
+
+1. 为 Secret [启用静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)；
+2. [启用 RBAC 规则来限制对 Secret 的读写操作](/zh/docs/reference/access-authn-authz/authorization/)。
+   要注意，任何被允许创建 Pod 的人都默认地具有读取 Secret 的权限。
+{{< /caution >}}
+
 <!-- body -->
 
 <!--
@@ -1243,7 +1263,7 @@ these pods.
 The `imagePullSecrets` field is a list of references to secrets in the same namespace.
 You can use an `imagePullSecrets` to pass a secret that contains a Docker (or other) image registry
 password to the kubelet. The kubelet uses this information to pull a private image on behalf of your Pod.
-See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field.
+See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field.
 
 #### Manually specifying an imagePullSecret
 
@@ -1254,7 +1274,8 @@ You can learn how to specify `ImagePullSecrets` from the [container images docum
 `imagePullSecrets` 字段中包含一个列表，列举对同一名字空间中的 Secret 的引用。
 你可以使用 `imagePullSecrets` 将包含 Docker（或其他）镜像仓库密码的 Secret 传递给
 kubelet。kubelet 使用此信息来替你的 Pod 拉取私有镜像。
-关于 `imagePullSecrets` 字段的更多信息，请参考 [PodSpec API](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#podspec-v1-core) 文档。
+关于 `imagePullSecrets` 字段的更多信息，请参考
+[PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 文档。
 
 #### 手动指定 imagePullSecret
 
@@ -1284,15 +1305,12 @@ Pod 将会将其的 imagePullSecret 字段设置为服务帐户的 imagePullSecr
 
 Manually created secrets (e.g. one containing a token for accessing a github account)
 can be automatically attached to pods based on their service account.
-See [Injecting Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset/) for a detailed explanation of that process.
 -->
 
 #### 自动挂载手动创建的 Secret
 
 手动创建的 Secret（例如包含用于访问 GitHub 帐户令牌的 Secret）可以
 根据其服务帐户自动附加到 Pod。
-请参阅[使用 PodPreset 向 Pod 中注入信息](/zh/docs/tasks/inject-data-application/podpreset/)
-以获取该过程的详细说明。
 
 <!--
 ## Details

content/zh/docs/concepts/workloads/pods/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "Pods"
+title: Pods
 content_type: concept
 weight: 10
 no_list: true
@@ -26,7 +26,7 @@ _Pods_ are the smallest deployable units of computing that you can create and ma
 
 A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
 {{< glossary_tooltip text="containers" term_id="container" >}}
-with shared storage/network resources, and a specification
+with shared storage and network resources, and a specification
 for how to run the containers. A Pod's contents are always co-located and
 co-scheduled, and run in a shared context. A Pod models an
 application-specific "logical host": it contains one or more application
@@ -350,6 +350,62 @@ changing existing code.
 这种抽象和关注点分离简化了整个系统的语义，并且使得用户可以在不改变现有代码的
 前提下就能扩展集群的行为。
 
+<!--
+## Pod update and replacement
+
+As mentioned in the previous section, when the Pod template for a workload
+resource is changed, the controller creates new Pods based on the updated
+template instead of updating or patching the existing Pods.
+-->
+## Pod 更新与替换   {#pod-update-and-replacement}
+
+正如前面章节所述，当某工作负载的 Pod 模板被改变时，控制器会基于更新的模板
+创建新的 Pod 对象而不是对现有 Pod 执行更新或者修补操作。
+
+<!--
+Kubernetes doesn't prevent you from managing Pods directly. It is possible to
+update some fields of a running Pod, in place. However, Pod update operations
+like 
+[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core), and
+[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)
+have some limitations:
+-->
+Kubernetes 并不禁止你直接管理 Pod。对运行中的 Pod 的某些字段执行就地更新操作
+还是可能的。不过，类似
+[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) 和
+[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)
+这类更新操作有一些限制：
+
+<!--
+- Most of the metadata about a Pod is immutable. For example, you cannot
+  change the `namespace`, `name`, `uid`, or `creationTimestamp` fields;
+  the `generation` field is unique. It only accepts updates that increment the
+  field's current value.
+- If the `metadata.deletionTimestamp` is set, no new entry can be added to the
+  `metadata.finalizers` list.
+- Pod updates may not change fields other than `spec.containers[*].image`,
+  `spec.initContainers[*].image`, `spec.activeDeadlineSeconds` or
+  `spec.tolerations`. For `spec.tolerations`, you can only add new entries.
+- When updating the `spec.activeDeadlineSeconds` field, two types of updates
+  are allowed:
+
+  1. setting the unassigned field to a positive number; 
+  1. updating the field from a positive number to a smaller, non-negative
+     number.
+-->
+- Pod 的绝大多数元数据都是不可变的。例如，你不可以改变其 `namespace`、`name`、
+  `uid` 或者 `creationTimestamp` 字段；`generation` 字段是比较特别的，如果更新
+  该字段，只能增加字段取值而不能减少。
+- 如果 `metadata.deletionTimestamp` 已经被设置，则不可以向 `metadata.finalizers`
+  列表中添加新的条目。
+- Pod 更新不可以改变除 `spec.containers[*].image`、`spec.initContainers[*].image`、
+  `spec.activeDeadlineSeconds` 或 `spec.tolerations` 之外的字段。
+  对于 `spec.tolerations`，你只被允许添加新的条目到其中。
+- 在更新`spec.activeDeadlineSeconds` 字段时，以下两种更新操作是被允许的：
+
+  1. 如果该字段尚未设置，可以将其设置为一个正数；
+  1. 如果该字段已经设置为一个正数，可以将其设置为一个更小的、非负的整数。
+
 <!--
 ## Resource sharing and communication
 
@@ -486,7 +542,6 @@ but cannot be controlled from there.
 
 <!--
 * Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
-* Learn about [PodPresets](/docs/concepts/workloads/pods/podpreset/).
 * Learn about [RuntimeClass](/docs/concepts/containers/runtime-class/) and how you can use it to
   configure different Pods with different container runtime configurations.
 * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
@@ -497,7 +552,6 @@ but cannot be controlled from there.
 * [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
 --
 * 了解 [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)
-* 了解 [PodPresets](/zh/docs/concepts/workloads/pods/podpreset/)
 * 了解 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)，以及如何使用它
   来配置不同的 Pod 使用不同的容器运行时配置
 * 了解 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
@@ -510,7 +564,7 @@ but cannot be controlled from there.
   中解释了在同一 Pod 中包含多个容器时的几种常见布局。
 
 <!--
-To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}, you can read about the prior art, including:
+To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}), you can read about the prior art, including:
 -->
 要了解为什么 Kubernetes 会在其他资源
 （如 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}

content/zh/docs/reference/access-authn-authz/admission-controllers.md

@@ -1117,19 +1117,6 @@ For more information about persistent volume claims, see [PersistentVolumeClaims
 关于持久化卷申领的更多信息，请参见
 [PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
 
-### PodPreset {#podpreset}
-
-<!--
-This admission controller injects a pod with the fields specified in a matching PodPreset.
-See also [PodPreset concept](/docs/concepts/workloads/pods/podpreset/) and
-[Inject Information into Pods Using a PodPreset](/docs/tasks/inject-data-application/podpreset)
-for more information.
--->
-该准入控制器根据与 PodPreset 中条件的匹配情况，将指定字段注入一个 Pod。
-另请参见 [PodPreset 概念](/zh/docs/concepts/workloads/pods/podpreset/)和
-[使用 PodPreset 将信息注入 Pod](/zh/docs/tasks/inject-data-application/podpreset)
-了解更多信息。
-
 ### PodSecurityPolicy {#podsecuritypolicy}
 
 <!--
@@ -1350,12 +1337,12 @@ versions 1.9 and later).
 <!--
 ## Is there a recommended set of admission controllers to use?
 
-Yes. For Kubernetes version 1.10 and later, the recommended admission controllers are enabled by default (shown [here](/docs/reference/command-line-tools-reference/kube-apiserver/#options)), so you do not need to explicitly specify them. You can enable additional admission controllers beyond the default set using the `--enable-admission-plugins` flag (**order doesn't matter**).
+Yes. The recommended admission controllers are enabled by default (shown [here](/docs/reference/command-line-tools-reference/kube-apiserver/#options)), so you do not need to explicitly specify them. You can enable additional admission controllers beyond the default set using the `--enable-admission-plugins` flag (**order doesn't matter**).
 -->
 ## 有推荐的准入控制器吗？
 
-有。对于 Kubernetes 1.10 以上的版本，推荐使用的准入控制器默认情况下都处于启用状态
-（查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。
+有。推荐使用的准入控制器默认情况下都处于启用状态
+（请查看[这里](/zh/docs/reference/command-line-tools-reference/kube-apiserver/#options)）。
 因此，你无需显式指定它们。
 你可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。
 
@@ -1366,31 +1353,3 @@ Yes. For Kubernetes version 1.10 and later, the recommended admission controller
 `--admission-control` 在 1.10 中已废弃，由 `--enable-admission-plugins` 取代。
 {{< /note >}}
 
-<!--
-For Kubernetes 1.9 and earlier, we recommend running the following set of admission controllers using the `--admission-control` flag (**order matters**).
--->
-对于 Kubernetes 1.9 及更早版本，我们建议使用 `--admission-control` 标志
-（**顺序很重要**）运行下面的一组准入控制器。
-
-* v1.9
-
-  ```shell
-  --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
-  ```
-
-  <!--
-  * It's worth reiterating that in 1.9, these happen in a mutating phase
-  and a validating phase, and that for example `ResourceQuota` runs in the validating
-  phase, and therefore is the last admission controller to run.
-  `MutatingAdmissionWebhook` appears before it in this list, because it runs
-  in the mutating phase.
-  -->
-  * 需要重申的是，在 1.9 中，它们都发生在变更阶段和验证阶段，例如 `ResourceQuota`
-    在验证阶段运行，因此是最后一个运行的准入控制器。
-    `MutatingAdmissionWebhook` 出现在此列表的前面，因为它在变更阶段运行。
-
-    <!--
-    For earlier versions, there was no concept of validating versus mutating and the
-    admission controllers ran in the exact order specified.
-    -->
-    对于更早期版本，没有验证和变更的概念，并且准入控制器按照指定的确切顺序运行。