From 3b0cbdab2461a6df302fb1554e7cbbef75a0e88c Mon Sep 17 00:00:00 2001
From: windsonsea <haifeng.yao@daocloud.io>
Date: Sun, 23 Apr 2023 10:42:54 +0800
Subject: [PATCH] [zh] sync declarative-config.md

---
 .../declarative-config.md                     | 662 ++++++++++++++----
 1 file changed, 513 insertions(+), 149 deletions(-)

diff --git a/content/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config.md
index ab56a90ab5..7e39e3babc 100644
--- a/content/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config.md
+++ b/content/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config.md
@@ -84,20 +84,19 @@ Following are definitions for terms used in this document:
 - *live object configuration / live configuration*: The live configuration
   values of an object, as observed by the Kubernetes cluster. These are kept in the Kubernetes
   cluster storage, typically etcd.
-- *declarative configuration writer /  declarative writer*: A person or software component
+- *declarative configuration writer / declarative writer*: A person or software component
   that makes updates to a live object. The live writers referred to in this topic make changes
   to object configuration files and run `kubectl apply` to write the changes.
 -->
 以下是本文档中使用的术语的定义：
 
-- *对象配置文件/配置文件*：一个定义 Kubernetes 对象的配置的文件。
+- **对象配置文件/配置文件**：一个定义 Kubernetes 对象的配置的文件。
   本主题展示如何将配置文件传递给 `kubectl apply`。
   配置文件通常存储于类似 Git 这种源码控制系统中。  
-- *现时对象配置/现时配置*：由 Kubernetes 集群所观测到的对象的现时配置值。
+- **现时对象配置/现时配置**：由 Kubernetes 集群所观测到的对象的现时配置值。
   这些配置保存在 Kubernetes 集群存储（通常是 etcd）中。
-- *声明式配置写者/声明式写者*：负责更新现时对象的人或者软件组件。
-  本主题中的声明式写者负责改变对象配置文件并执行 `kubectl apply` 命令
-  以写入变更。
+- **声明式配置写者/声明式写者**：负责更新现时对象的人或者软件组件。
+  本主题中的声明式写者负责改变对象配置文件并执行 `kubectl apply` 命令以写入变更。
 
 <!--
 ## How to create objects
@@ -106,7 +105,7 @@ Use `kubectl apply` to create all objects, except those that already exist,
 defined by configuration files in a specified directory:
 
 ```shell
-kubectl apply -f <directory>/
+kubectl apply -f <directory>
 ```
 
 This sets the `kubectl.kubernetes.io/last-applied-configuration: '{...}'`
@@ -118,16 +117,16 @@ configuration file that was used to create the object.
 使用 `kubectl apply` 来创建指定目录中配置文件所定义的所有对象，除非对应对象已经存在：
 
 ```shell
-kubectl apply -f <目录>/
+kubectl apply -f <目录>
 ```
 
 此操作会在每个对象上设置 `kubectl.kubernetes.io/last-applied-configuration: '{...}'`
 注解。注解值中包含了用来创建对象的配置文件的内容。
 
+{{< note >}}
 <!--
 Add the `-R` flag to recursively process directories.
 -->
-{{< note >}}
 添加 `-R` 标志可以递归地处理目录。
 {{< /note >}}
 
@@ -147,6 +146,7 @@ Run `kubectl diff` to print the object that will be created:
 kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml
 ```
 
+{{< note >}}
 <!--
 `diff` uses [server-side dry-run](/docs/reference/using-api/api-concepts/#dry-run),
 which needs to be enabled on `kube-apiserver`.
@@ -156,14 +156,12 @@ it requires granting `PATCH`, `CREATE`, and `UPDATE` permissions.
 See [Dry-Run Authorization](/docs/reference/using-api/api-concepts#dry-run-authorization)
 for details.
 -->
-{{< note >}}
 `diff` 使用[服务器端试运行（Server-side Dry-run）](/zh-cn/docs/reference/using-api/api-concepts/#dry-run)
 功能特性；而该功能特性需要在 `kube-apiserver` 上启用。
 
-由于 `diff` 操作会使用试运行模式执行服务器端 apply 请求，因此需要为
-用户配置 `PATCH`、`CREATE` 和 `UPDATE` 操作权限。
-参阅[试运行授权](/zh-cn/docs/reference/using-api/api-concepts#dry-run-authorization)
-了解详情。
+由于 `diff` 操作会使用试运行模式执行服务器端 apply 请求，因此需要为用户配置
+`PATCH`、`CREATE` 和 `UPDATE` 操作权限。
+参阅[试运行授权](/zh-cn/docs/reference/using-api/api-concepts#dry-run-authorization)了解详情。
 {{< /note >}}
 
 <!--
@@ -188,9 +186,10 @@ kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yam
 The output shows that the `kubectl.kubernetes.io/last-applied-configuration` annotation
 was written to the live configuration, and it matches the configuration file:
 -->
-输出显示注解 `kubectl.kubernetes.io/last-applied-configuration` 被写入到
-现时配置中，并且其内容与配置文件相同：
+输出显示注解 `kubectl.kubernetes.io/last-applied-configuration`
+被写入到现时配置中，并且其内容与配置文件相同：
 
+<!--
 ```yaml
 kind: Deployment
 metadata:
@@ -198,6 +197,15 @@ metadata:
     # ...
     # This is the json representation of simple_deployment.yaml
     # It was written by kubectl apply when the object was created
+```
+-->
+```yaml
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    # 此为 simple_deployment.yaml 的 JSON 表示
+    # 在对象创建时由 kubectl apply 命令写入
     kubectl.kubernetes.io/last-applied-configuration: |
       {"apiVersion":"apps/v1","kind":"Deployment",
       "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
@@ -240,8 +248,8 @@ if those objects already exist. This approach accomplishes the following:
 2. Clears fields removed from the configuration file in the live configuration.
 
 ```shell
-kubectl diff -f <directory>/
-kubectl apply -f <directory>/
+kubectl diff -f <directory>
+kubectl apply -f <directory>
 ```
 -->
 ## 如何更新对象   {#how-to-update-objects}
@@ -253,14 +261,14 @@ kubectl apply -f <directory>/
 2. 在现时配置中清除配置文件中已删除的字段。
 
 ```shell
-kubectl diff -f <目录>/
-kubectl apply -f <目录>/
+kubectl diff -f <目录>
+kubectl apply -f <目录>
 ```
 
+{{< note >}}
 <!--
 Add the `-R` flag to recursively process directories.
 -->
-{{< note >}}
 使用 `-R` 标志递归处理目录。
 {{< /note >}}
 
@@ -280,11 +288,11 @@ Create the object using `kubectl apply`:
 kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
 ```
 
+{{< note >}}
 <!--
 For purposes of illustration, the preceding command refers to a single
 configuration file instead of a directory.
 -->
-{{< note >}}
 出于演示的目的，上面的命令引用的是单个文件而不是整个目录。
 {{< /note >}}
 
@@ -301,9 +309,25 @@ kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yam
 The output shows that the `kubectl.kubernetes.io/last-applied-configuration` annotation
 was written to the live configuration, and it matches the configuration file:
 -->
-输出显示，注解 `kubectl.kubernetes.io/last-applied-configuration` 被写入到
-现时配置中，并且其取值与配置文件内容相同。
+输出显示，注解 `kubectl.kubernetes.io/last-applied-configuration`
+被写入到现时配置中，并且其取值与配置文件内容相同。
 
+<!--
+```yaml
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    # This is the json representation of simple_deployment.yaml
+    # It was written by kubectl apply when the object was created
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"apps/v1","kind":"Deployment",
+      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+      "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
+      "ports":[{"containerPort":80}]}]}}}}
+```
+-->
 ```yaml
 kind: Deployment
 metadata:
@@ -367,9 +391,14 @@ kubectl get deployment nginx-deployment -o yaml
 The output shows that the `replicas` field has been set to 2, and the `last-applied-configuration`
 annotation does not contain a `replicas` field:
 -->
-输出显示，`replicas` 字段已经被设置为 2，而 `last-applied-configuration` 注解中
-并不包含 `replicas` 字段。
+输出显示，`replicas` 字段已经被设置为 2，而 `last-applied-configuration`
+注解中并不包含 `replicas` 字段。
 
+<!--
+# note that the annotation does not contain replicas
+# because it was not updated through apply
+# written by scale
+-->
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -386,7 +415,7 @@ metadata:
       "ports":[{"containerPort":80}]}]}}}}
   # ...
 spec:
-  replicas: 2 # written by scale
+  replicas: 2 # 由 scale 命令填写
   # ...
   minReadySeconds: 5
   selector:
@@ -455,6 +484,40 @@ The output shows the following changes to the live configuration:
 * 字段 `minReadySeconds` 被移除。
 * 注解 `last-applied-configuration` 中不再包含 `minReadySeconds` 字段。
 
+<!--
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    # The annotation contains the updated image to nginx 1.16.1,
+    # but does not contain the updated replicas to 2
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"apps/v1","kind":"Deployment",
+      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+      "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
+      "ports":[{"containerPort":80}]}]}}}}
+    # ...
+spec:
+  replicas: 2 # Set by `kubectl scale`.  Ignored by `kubectl apply`.
+  # minReadySeconds cleared by `kubectl apply`
+  # ...
+  selector:
+    matchLabels:
+      # ...
+      app: nginx
+  template:
+    metadata:
+      # ...
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: nginx:1.16.1 # Set by `kubectl apply`
+```
+-->
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -496,17 +559,17 @@ spec:
   # ...
 ```
 
+{{< warning >}}
 <!--
 Mixing `kubectl apply` with the imperative object configuration commands
 `create` and `replace` is not supported. This is because `create`
 and `replace` do not retain the `kubectl.kubernetes.io/last-applied-configuration`
 that `kubectl apply` uses to compute updates.
 -->
-{{< warning >}}
 将 `kubectl apply` 与指令式对象配置命令 `kubectl create` 或 `kubectl replace`
 混合使用是不受支持的。这是因为 `create` 和 `replace` 命令都不会保留
 `kubectl apply` 用来计算更新内容所使用的
- `kubectl.kubernetes.io/last-applied-configuration` 注解值。
+`kubectl.kubernetes.io/last-applied-configuration` 注解值。
 {{< /warning >}}
 
 <!--
@@ -530,76 +593,209 @@ kubectl delete -f <filename>
 
 ### 建议操作：`kubectl delete -f <文件名>`
 
-使用指令式命令来手动删除对象是建议的方法，因为这种方法更为明确地给出了
-要删除的内容是什么，且不容易造成用户不小心删除了其他对象的情况。
+使用指令式命令来手动删除对象是建议的方法，因为这种方法更为明确地给出了要删除的内容是什么，
+且不容易造成用户不小心删除了其他对象的情况。
 
 ```shell
 kubectl delete -f <文件名>
 ```
 
 <!--
-### Alternative: `kubectl apply -f <directory/> --prune -l your=label`
+### Alternative: `kubectl apply -f <directory> --prune`
 
-Only use this if you know what you are doing.
+As an alternative to `kubectl delete`, you can use `kubectl apply` to identify objects to be deleted after
+their manifests have been removed from a directory in the local filesystem.
 -->
-### 替代方式：`kubectl apply -f <目录名称/> --prune -l your=label`
+### 替代方式：`kubectl apply -f <目录> --prune`
 
-只有在充分理解此命令背后含义的情况下才建议这样操作。
+作为 `kubectl delete` 操作的替代方式，你可以在本地文件系统的目录中的清单文件被删除之后，
+使用 `kubectl apply` 来辩识要删除的对象。
 
 <!--
-`kubectl apply --prune` is in alpha, and backwards incompatible
-changes might be introduced in subsequent releases.
+In Kubernetes {{< skew currentVersion >}}, there are two pruning modes available in kubectl apply:
+
+- Allowlist-based pruning: This mode has existed since kubectl v1.5 but is still
+  in alpha due to usability, correctness and performance issues with its design.
+  The ApplySet-based mode is designed to replace it.
+- ApplySet-based pruning: An _apply set_ is a server-side object (by default, a Secret)
+  that kubectl can use to accurately and efficiently track set membership across **apply**
+  operations. This mode was introduced in alpha in kubectl v1.27 as a replacement for allowlist-based pruning.
 -->
-{{< warning >}}
-`kubectl apply --prune` 命令本身仍处于 Alpha 状态，在后续发布版本中可能会
-引入一些向后不兼容的变化。
-{{< /warning >}}
+在 Kubernetes {{< skew currentVersion >}} 中，`kubectl apply` 可使用两种剪裁模式：
+
+- 基于 Allowlist 的剪裁：这种模式自 kubectl v1.5 版本开始就存在，
+  但由于其设计存在易用性、正确性和性能问题，因此仍处于 Alpha 阶段。
+  基于 ApplySet 的模式设计用于取代这种模式。
+- 基于 ApplySet 的剪裁：**apply set** 是一个服务器端对象（默认是一个 Secret），
+  kubectl 可以使用它来在 **apply** 操作中准确高效地跟踪集合成员。
+  这种模式在 kubectl v1.27 中以 Alpha 引入，作为基于 Allowlist 剪裁的替代方案。
+
+{{< tabs name="kubectl_apply_prune" >}}
+{{% tab name="Allow list" %}}
+
+{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
 
 {{< warning >}}
 <!--
-You must be careful when using this command, so that you
-do not delete objects unintentionally.
+Take care when using `--prune` with `kubectl apply` in allow list mode. Which
+objects are pruned depends on the values of the `--prune-allowlist`, `--selector`
+and `--namespace` flags, and relies on dynamic discovery of the objects in scope.
+Especially if flag values are changed between invocations, this can lead to objects
+being unexpectedly deleted or retained.
 -->
-在使用此命令时必须小心，这样才不会无意中删除不想删除的对象。
+在 Allowlist 模式下使用 `kubectl apply` 命令时要小心使用 `--prune` 标志。
+哪些对象被剪裁取决于 `--prune-allowlist`、`--selector` 和 `--namespace` 标志的值，
+并且依赖于作用域中对象的动态发现。特别是在调用之间更改标志值时，这可能会导致对象被意外删除或保留。
 {{< /warning >}}
 
 <!--
-As an alternative to `kubectl delete`, you can use `kubectl apply` to identify objects to be deleted after their
-configuration files have been removed from the directory. Apply with `--prune`
-queries the API server for all objects matching a set of labels, and attempts
-to match the returned live object configurations against the object
-configuration files. If an object matches the query, and it does not have a
-configuration file in the directory, and it has a `last-applied-configuration` annotation,
+To use allowlist-based pruning, add the following flags to your `kubectl apply` invocation:
+
+- `--prune`: Delete previously applied objects that are not in the set passed to the current invocation.
+- `--prune-allowlist`: A list of group-version-kinds (GVKs) to consider for pruning.
+  This flag is optional but strongly encouraged, as its default value is a partial
+  list of both namespaced and cluster-scoped types, which can lead to surprising results.
+- `--selector/-l`: Use a label selector to constrain the set of objects selected
+  for pruning. This flag is optional but strongly encouraged.
+- `--all`: use instead of `--selector/-l` to explicitly select all previously
+  applied objects of the allowlisted types.
+-->
+要使用基于 Allowlist 的剪裁，可以添加以下标志到你的 `kubectl apply` 调用：
+
+- `--prune`：删除之前应用的、不在当前调用所传递的集合中的对象。
+- `--prune-allowlist`：一个需要考虑进行剪裁的组-版本-类别（group-version-kind, GVK）列表。
+  这个标志是可选的，但强烈建议使用，因为它的默认值是同时作用于命名空间和集群的部分类型列表，
+  这可能会产生令人意外的结果。
+- `--selector/-l`：使用标签选择算符以约束要剪裁的对象的集合。此标志是可选的，但强烈建议使用。
+- `--all`：用于替代 `--selector/-l` 以显式选择之前应用的类型为 Allowlist 的所有对象。
+
+<!--
+Allowlist-based pruning queries the API server for all objects of the allowlisted GVKs that match the given labels (if any), and attempts to match the returned live object configurations against the object
+manifest files. If an object matches the query, and it does not have a
+manifest in the directory, and it has a `kubectl.kubernetes.io/last-applied-configuration` annotation,
 it is deleted.
 -->
-作为 `kubectl delete` 操作的替代方式，你可以在目录中对象配置文件被删除之后，
-使用 `kubectl apply` 来辩识要删除的对象。
-带 `--prune` 标志的 `apply` 命令会首先查询 API 服务器，获得与某组标签相匹配
-的对象列表，之后将返回的现时对象配置与目录中的对象配置文件相比较。
-如果某对象在查询中被匹配到，但在目录中没有文件与其相对应，并且其中还包含
-`last-applied-configuration` 注解，则该对象会被删除。 
-
-{{< comment >}}
-TODO(pwittrock): We need to change the behavior to prevent the user from running apply on subdirectories unintentionally.
-{{< /comment >}}
+基于 Allowlist 的剪裁会查询 API 服务器以获取与给定标签（如果有）匹配的所有允许列出的 GVK 对象，
+并尝试将返回的活动对象配置与对象清单文件进行匹配。如果一个对象与查询匹配，并且它在目录中没有对应的清单，
+但它有一个 `kubectl.kubernetes.io/last-applied-configuration` 注解，则它将被删除。
 
+<!--
 ```shell
-kubectl apply -f <directory/> --prune -l <labels>
+kubectl apply -f <directory> --prune -l <labels> --prune-allowlist=<gvk-list>
+```
+-->
+```shell
+kubectl apply -f <目录> --prune -l <标签> --prune-allowlist=<gvk 列表>
+```
+
+{{< warning >}}
+<!--
+Apply with prune should only be run against the root directory
+containing the object manifests. Running against sub-directories
+can cause objects to be unintentionally deleted if they were previously applied, 
+have the labels given (if any), and do not appear in the subdirectory.
+-->
+带剪裁（prune）行为的 `apply` 操作应在包含对象清单的根目录运行。
+如果对象之前被执行了 `apply` 操作，具有给定的标签（如果有）且未出现在子目录中，
+在其子目录中运行可能导致对象被不小心删除。
+{{< /warning >}}
+
+{{% /tab %}}
+
+{{% tab name="Apply set" %}}
+
+{{< feature-state for_k8s_version="v1.27" state="alpha" >}}
+
+{{< caution >}}
+<!--
+`kubectl apply --prune --applyset` is in alpha, and backwards incompatible
+changes might be introduced in subsequent releases.
+-->
+`kubectl apply --prune --applyset` 目前处于 Alpha 阶段，在后续的版本中可能引入向后不兼容的变更。
+{{< /caution >}}
+
+<!--
+To use ApplySet-based pruning, set the `KUBECTL_APPLYSET=true` environment variable,
+and add the following flags to your `kubectl apply` invocation:
+- `--prune`: Delete previously applied objects that are not in the set passed
+  to the current invocation.
+- `--applyset`: The name of an object that kubectl can use to accurately and
+  efficiently track set membership across `apply` operations.
+-->
+要使用基于 ApplySet 的剪裁，请设置 `KUBECTL_APPLYSET=true` 环境变量，
+并添加以下标志到你的 `kubectl apply` 调用中：
+
+- `--prune`：删除之前应用的、不在当前调用所传递的集合中的对象。
+- `--applyset`：是 kubectl 可以使用的对象的名称，用于在 `apply` 操作中准确高效地跟踪集合成员。
+
+<!--
+```shell
+KUBECTL_APPLYSET=true kubectl apply -f <directory> --prune --applyset=<name>
+```
+-->
+```shell
+KUBECTL_APPLYSET=true kubectl apply -f <目录> --prune --applyset=<名称>
 ```
 
 <!--
-Apply with prune should only be run against the root directory
-containing the object configuration files. Running against sub-directories
-can cause objects to be unintentionally deleted if they are returned
-by the label selector query specified with `-l <labels>` and
-do not appear in the subdirectory.
+By default, the type of the ApplySet parent object used is a Secret. However,
+ConfigMaps can also be used in the format: `--applyset=configmaps/<name>`.
+When using a Secret or ConfigMap, kubectl will create the object if it does not already exist.
 -->
-{{< warning >}}
-带剪裁（prune）行为的 `apply` 操作应在包含对象配置文件的目录的根目录运行。
-如果在其子目录中运行，可能导致对象被不小心删除。
-因为某些对象可能与 `-l <标签>` 的标签选择算符匹配，但其配置文件不在当前
-子目录下。
-{{< /warning >}}
+默认情况下，所使用的 ApplySet 父对象的类别是 Secret。
+不过也可以按格式 `--applyset=configmaps/<name>` 使用 ConfigMap。
+使用 Secret 或 ConfigMap 时，如果对应对象尚不存在，kubectl 将创建这些对象。
+
+<!--
+It is also possible to use custom resources as ApplySet parent objects. To enable
+this, label the Custom Resource Definition (CRD) that defines the resource you want
+to use with the following: `applyset.kubernetes.io/is-parent-type: true`. Then, create
+the object you want to use as an ApplySet parent (kubectl does not do this automatically
+for custom resources). Finally, refer to that object in the applyset flag as follows:
+`--applyset=<resource>.<group>/<name>` (for example, `widgets.custom.example.com/widget-name`).
+-->
+还可以使用自定义资源作为 ApplySet 父对象。
+要启用此功能，请为定义目标资源的 CRD 打上标签：`applyset.kubernetes.io/is-parent-type: true`。
+然后，创建你想要用作 ApplySet 父级的对象（kubectl 不会自动为自定义资源执行此操作）。
+最后，按以下方式在 applyset 标志中引用该对象： `--applyset=<resource>.<group>/<name>`
+（例如 `widgets.custom.example.com/widget-name`）。
+
+<!--
+With ApplySet-based pruning, kubectl adds the `applyset.kubernetes.io/part-of=<parentID>`
+label to each object in the set before they are sent to the server. For performance reasons,
+it also collects the list of resource types and namespaces that the set contains and adds
+these in annotations on the live parent object. Finally, at the end of the apply operation,
+it queries the API server for objects of those types in those namespaces
+(or in the cluster scope, as applicable) that belong to the set, as defined by the
+`applyset.kubernetes.io/part-of=<parentID>` label.
+-->
+使用基于 ApplySet 的剪裁时，kubectl 会在将集合中的对象发送到服务器之前将标签
+`applyset.kubernetes.io/part-of=<parentID>` 添加到集合中的每个对象上。
+出于性能原因，它还会将该集合包含的资源类型和命名空间列表收集到当前父对象上的注解中。
+最后，在 apply 操作结束时，它会在 API 服务器上查找由 `applyset.kubernetes.io/part-of=<parentID>`
+标签定义的、属于此集合所对应命名空间（或适用的集群作用域）中对应类型的对象。
+
+<!--
+Caveats and restrictions:
+
+- Each object may be a member of at most one set.
+- The `--namespace` flag is required when using any namespaced parent, including
+  the default Secret.  This means that ApplySets spanning multiple namespaces must
+  use a cluster-scoped custom resource as the parent object.
+- To safely use ApplySet-based pruning with multiple directories,
+  use a unique ApplySet name for each.
+-->
+注意事项和限制：
+
+- 每个对象最多可以是一个集合的成员。
+- 当使用任何名命名空间的父级（包括默认的 Secret）时，
+  `--namespace` 标志是必需的。这意味着跨越多个命名空间的
+  ApplySet 必须使用集群作用域的自定义资源作为父对象。
+- 要安全地在多个目录中使用基于 ApplySet 的剪裁，请为每个目录使用唯一的 ApplySet 名称。
+
+{{% /tab %}}
+
+{{< /tabs >}}
 
 <!--
 ## How to view an object
@@ -620,15 +816,16 @@ kubectl get -f <文件名 | URL> -o yaml
 
 <!--
 ## How apply calculates differences and merges changes
+-->
+## apply 操作是如何计算配置差异并合并变更的？   {#how-apply-diffs-and-merge-changes}
 
+{{< caution >}}
+<!--
 A *patch* is an update operation that is scoped to specific fields of an object
 instead of the entire object. This enables updating only a specific set of fields
 on an object without reading the object first.
 -->
-## apply 操作是如何计算配置差异并合并变更的？
-
-{{< caution >}}
-*patch* 是一种更新操作，其作用域为对象的一些特定字段而不是整个对象。
+**patch** 是一种更新操作，其作用域为对象的一些特定字段而不是整个对象。
 这使得你可以更新对象的特定字段集合而不必先要读回对象。
 {{< /caution >}}
 
@@ -640,9 +837,8 @@ configuration. The `kubectl apply` command calculates this patch request
 using the configuration file, the live configuration, and the
 `last-applied-configuration` annotation stored in the live configuration.
 -->
-`kubectl apply` 更新对象的现时配置，它是通过向 API 服务器发送一个 patch 请求
-来执行更新动作的。
-所提交的补丁中定义了对现时对象配置中特定字段的更新。
+`kubectl apply` 更新对象的现时配置，它是通过向 API 服务器发送一个 patch
+请求来执行更新动作的。所提交的补丁中定义了对现时对象配置中特定字段的更新。
 `kubectl apply` 命令会使用当前的配置文件、现时配置以及现时配置中保存的
 `last-applied-configuration` 注解内容来计算补丁更新内容。
 
@@ -663,13 +859,15 @@ to calculate which fields should be deleted or set:
 用来计算要删除或设置哪些字段的步骤如下：
 
 <!--
-1. Calculate the fields to delete. These are the fields present in `last-applied-configuration` and missing from the configuration file.
-2. Calculate the fields to add or set. These are the fields present in the configuration file whose values don't match the live configuration.
+1. Calculate the fields to delete. These are the fields present in
+   `last-applied-configuration` and missing from the configuration file.
+2. Calculate the fields to add or set. These are the fields present in
+   the configuration file whose values don't match the live configuration.
 
 Here's an example. Suppose this is the configuration file for a Deployment object:
 -->
-1. 计算要删除的字段，即在 `last-applied-configuration` 中存在但在
-   配置文件中不再存在的字段。
+1. 计算要删除的字段，即在 `last-applied-configuration`
+   中存在但在配置文件中不再存在的字段。
 2. 计算要添加或设置的字段，即在配置文件中存在但其取值与现时配置不同的字段。
 
 下面是一个例子。假定此文件是某 Deployment 对象的配置文件：
@@ -681,6 +879,26 @@ Also, suppose this is the live configuration for the same Deployment object:
 -->
 同时假定同一 Deployment 对象的现时配置如下：
 
+<!--
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    # note that the annotation does not contain replicas
+    # because it was not updated through apply
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"apps/v1","kind":"Deployment",
+      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+      "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+      "spec":{"containers":[{"image":"nginx:1.14.2","name":"nginx",
+      "ports":[{"containerPort":80}]}]}}}}
+  # ...
+spec:
+  replicas: 2 # written by scale
+```
+-->
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -697,7 +915,7 @@ metadata:
       "ports":[{"containerPort":80}]}]}}}}
   # ...
 spec:
-  replicas: 2 # written by scale
+  replicas: 2 # 按规模填写
   # ...
   minReadySeconds: 5
   selector:
@@ -729,11 +947,11 @@ Here are the merge calculations that would be performed by `kubectl apply`:
    regardless of whether they appear in the `last-applied-configuration`.
    In this example, `minReadySeconds` appears in the
    `last-applied-configuration` annotation, but does not appear in the configuration file.
-    **Action:** Clear `minReadySeconds` from the live configuration.
+   **Action:** Clear `minReadySeconds` from the live configuration.
 2. Calculate the fields to set by reading values from the configuration
    file and comparing them to values in the live configuration. In this example,
    the value of `image` in the configuration file does not match
-    the value in the live configuration. **Action:** Set the value of `image` in the live configuration.
+   the value in the live configuration. **Action:** Set the value of `image` in the live configuration.
 3. Set the `last-applied-configuration` annotation to match the value
    of the configuration file.
 4. Merge the results from 1, 2, 3 into a single patch request to the API server.
@@ -746,8 +964,8 @@ Here is the live configuration that is the result of the merge:
    计算要删除的字段。
    对于本地对象配置文件中显式设置为空的字段，清除其在现时配置中的设置，
    无论这些字段是否出现在 `last-applied-configuration` 中。
-   在此例中，`minReadySeconds` 出现在 `last-applied-configuration` 注解中，但
-   并不存在于配置文件中。
+   在此例中，`minReadySeconds` 出现在 `last-applied-configuration` 注解中，
+   但并不存在于配置文件中。
    **动作：** 从现时配置中删除 `minReadySeconds` 字段。
 2. 通过读取配置文件中的值并将其与现时配置相比较，计算要设置的字段。
    在这个例子中，配置文件中的 `image` 值与现时配置中的 `image` 不匹配。
@@ -757,6 +975,31 @@ Here is the live configuration that is the result of the merge:
 
 下面是此合并操作之后形成的现时配置：
 
+<!--
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  annotations:
+    # ...
+    # The annotation contains the updated image to nginx 1.16.1,
+    # but does not contain the updated replicas to 2
+    kubectl.kubernetes.io/last-applied-configuration: |
+      {"apiVersion":"apps/v1","kind":"Deployment",
+      "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"},
+      "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}},
+      "spec":{"containers":[{"image":"nginx:1.16.1","name":"nginx",
+      "ports":[{"containerPort":80}]}]}}}}
+    # ...
+spec:
+  selector:
+    matchLabels:
+      # ...
+      app: nginx
+  replicas: 2 # Set by `kubectl scale`.  Ignored by `kubectl apply`.
+  # minReadySeconds cleared by `kubectl apply`
+```
+-->
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -778,7 +1021,7 @@ spec:
       # ...
       app: nginx
   replicas: 2 # 由 `kubectl scale` 设置，被 `kubectl apply` 命令忽略
-  # minReadySeconds  此字段被`kubectl apply`清除
+  # minReadySeconds  此字段被 `kubectl apply` 清除
   # ...
   template:
     metadata:
@@ -820,17 +1063,17 @@ type of the field. There are several types of fields:
 - *list*: A field containing a list of items that can be either primitive types or maps.
   For example, `containers`, `ports`, and `args` are lists. **Action:** Varies.
 -->
-- *基本类型*：字段类型为 `string`、`integer` 或 `boolean` 之一。
+- **基本类型**：字段类型为 `string`、`integer` 或 `boolean` 之一。
   例如：`image` 和 `replicas` 字段都是基本类型字段。
 
   **动作：** 替换。
 
-- *map*：也称作 *object*。类型为 `map` 或包含子域的复杂结构。例如，`labels`、
+- **map**：也称作 *object*。类型为 `map` 或包含子域的复杂结构。例如，`labels`、
   `annotations`、`spec` 和 `metadata` 都是 map。
 
   **动作：** 合并元素或子字段。
 
-- *list*：包含元素列表的字段，其中每个元素可以是基本类型或 map。
+- **list**：包含元素列表的字段，其中每个元素可以是基本类型或 map。
   例如，`containers`、`ports` 和 `args` 都是 list。
 
   **动作：** 不一定。
@@ -842,9 +1085,9 @@ For instance, when merging the `spec` on a Deployment, the entire `spec` is
 not replaced. Instead the subfields of `spec`, such as `replicas`, are compared
 and merged.
 -->
-当 `kubectl apply` 更新某个 map 或 list 字段时，它通常不会替换整个字段，而是会
-更新其中的各个子元素。例如，当合并 Deployment 的 `spec` 时，`kubectl` 并不会
-将其整个替换掉。相反，实际操作会是对 `replicas` 这类 `spec`
+当 `kubectl apply` 更新某个 map 或 list 字段时，它通常不会替换整个字段，
+而是会更新其中的各个子元素。例如，当合并 Deployment 的 `spec` 时，`kubectl`
+并不会将其整个替换掉。相反，实际操作会是对 `replicas` 这类 `spec`
 的子字段来执行比较和更新。
 
 <!--
@@ -856,13 +1099,21 @@ Primitive fields are replaced or cleared.
 
 基本类型字段会被替换或清除。
 
+{{< note >}}
 <!--
 `-` is used for "not applicable" because the value is not used.
 -->
-{{< note >}}
 `-` 表示的是“不适用”，因为指定数值未被使用。
 {{< /note >}}
 
+<!--
+| Field in object configuration file  | Field in live object configuration | Field in last-applied-configuration | Action                                    |
+|-------------------------------------|------------------------------------|-------------------------------------|-------------------------------------------|
+| Yes                                 | Yes                                | -                                   | Set live to configuration file value.  |
+| Yes                                 | No                                 | -                                   | Set live to local configuration.           |
+| No                                  | -                                  | Yes                                 | Clear from live configuration.            |
+| No                                  | -                                  | No                                  | Do nothing. Keep live value.             |
+-->
 | 字段在对象配置文件中  | 字段在现时对象配置中 | 字段在 `last-applied-configuration` 中 | 动作 |
 |-----------------------|----------------------|----------------------------------------|------|
 | 是 | 是 | -  | 将配置文件中值设置到现时配置上。 |
@@ -879,13 +1130,21 @@ Fields that represent maps are merged by comparing each of the subfields or elem
 
 用来表示映射的字段在合并时会逐个子字段或元素地比较：
 
+{{< note >}}
 <!--
 `-` is used for "not applicable" because the value is not used.
 -->
-{{< note >}}
 `-` 表示的是“不适用”，因为指定数值未被使用。
 {{< /note >}}
 
+<!--
+| Key in object configuration file    | Key in live object configuration   | Field in last-applied-configuration | Action                           |
+|-------------------------------------|------------------------------------|-------------------------------------|----------------------------------|
+| Yes                                 | Yes                                | -                                   | Compare sub fields values.        |
+| Yes                                 | No                                 | -                                   | Set live to local configuration.  |
+| No                                  | -                                  | Yes                                 | Delete from live configuration.   |
+| No                                  | -                                  | No                                  | Do nothing. Keep live value.     |
+-->
 | 键存在于对象配置文件中 | 键存在于现时对象配置中 | 键存在于 `last-applied-configuration` 中 | 动作 |
 |------------------------|------------------------|------------------------------------------|------|
 | 是 | 是 | -  | 比较子域取值。 |
@@ -932,8 +1191,8 @@ Any `args` elements that had previously been added to the live configuration are
 The order of the `args` elements defined in the configuration file is
 retained in the live configuration.
 -->
-**示例：** 使用 `kubectl apply` 来更新 Pod 中 Container 的 `args` 字段。此操作会
-将现时配置中的 `args` 值设为配置文件中的值。
+**示例：** 使用 `kubectl apply` 来更新 Pod 中 Container 的 `args` 字段。
+此操作会将现时配置中的 `args` 值设为配置文件中的值。
 所有之前添加到现时配置中的 `args` 元素都会丢失。
 配置文件中的 `args` 元素的顺序在被添加到现时配置中时保持不变。
 
@@ -994,10 +1253,10 @@ This merges the list as though it was a map where each element is keyed
 by `name`.
 -->
 此合并策略会使用每个字段上的一个名为 `patchMergeKey` 的特殊标签。
-Kubernetes 源代码文件 [types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2747)
-为每个字段定义了 `patchMergeKey`。
-当合并由 map 组成的 list 时，给定元素中被设置为 `patchMergeKey` 的字段会被
-当做该元素的 map 键值来使用。
+Kubernetes 源代码中为每个字段定义了 `patchMergeKey`：
+[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2747)。
+当合并由 map 组成的 list 时，给定元素中被设置为 `patchMergeKey`
+的字段会被当做该元素的 map 键值来使用。
 
 **例如：** 使用 `kubectl apply` 来更新 Pod 规约中的 `containers` 字段。
 此操作会将 `containers` 列表视作一个映射来执行合并，每个元素的主键为 `name`。
@@ -1117,8 +1376,7 @@ Kubernetes 源代码文件 [types.go](https://github.com/kubernetes/api/blob/d04
   `kubectl apply` 能够辩识出现时配置中的容器 "nginx-helper-b" 与配置文件
   中的容器 "nginx-helper-b" 相同，即使它们的字段值有些不同（配置文件中未给定
   `args` 值）。这是因为 `patchMergeKey` 字段（name）的值在两个版本中都一样。
-- 名为 "nginx-helper-c" 的容器是新增的，因为在配置文件中的这个容器尚不存在
-  于现时配置中。
+- 名为 "nginx-helper-c" 的容器是新增的，因为在配置文件中的这个容器尚不存在于现时配置中。
 - 名为 "nginx-helper-d" 的容器被保留下来，因为在 last-applied-configuration
   中没有与之同名的元素。
 
@@ -1131,15 +1389,15 @@ As of Kubernetes 1.5, merging lists of primitive elements is not supported.
 
 在 Kubernetes 1.5 中，尚不支持对由基本类型元素构成的 list 进行合并。
 
+{{< note >}}
 <!--
 Which of the above strategies is chosen for a given field is controlled by
 the `patchStrategy` tag in [types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2748)
 If no `patchStrategy` is specified for a field of type list, then
 the list is replaced.
 -->
-{{< note >}}
-选择上述哪种策略是由源码中给定字段的 `patchStrategy` 标记来控制的： 
-[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2748)
+选择上述哪种策略是由源码中给定字段的 `patchStrategy` 标记来控制的：
+[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2748)。
 如果 list 类型字段未设置 `patchStrategy`，则整个 list 会被替换掉。
 {{< /note >}}
 
@@ -1195,6 +1453,44 @@ configuration. These fields were not specified in the configuration file.
 输出显示 API 在现时配置中为某些字段设置了默认值。
 这些字段在配置文件中并未设置。
 
+<!--
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+# ...
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  minReadySeconds: 5
+  replicas: 1 # defaulted by apiserver
+  strategy:
+    rollingUpdate: # defaulted by apiserver - derived from strategy.type
+      maxSurge: 1
+      maxUnavailable: 1
+    type: RollingUpdate # defaulted by apiserver
+  template:
+    metadata:
+      creationTimestamp: null
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - image: nginx:1.14.2
+        imagePullPolicy: IfNotPresent # defaulted by apiserver
+        name: nginx
+        ports:
+        - containerPort: 80
+          protocol: TCP # defaulted by apiserver
+        resources: {} # defaulted by apiserver
+        terminationMessagePath: /dev/termination-log # defaulted by apiserver
+      dnsPolicy: ClusterFirst # defaulted by apiserver
+      restartPolicy: Always # defaulted by apiserver
+      securityContext: {} # defaulted by apiserver
+      terminationGracePeriodSeconds: 30 # defaulted by apiserver
+# ...
+```
+-->
 ```yaml
 apiVersion: apps/v1
 kind: Deployment
@@ -1240,8 +1536,8 @@ on the values of other fields. When the other fields are later changed,
 the values defaulted from them will not be updated unless they are
 explicitly cleared.
 -->
-在补丁请求中，已经设置了默认值的字段不会被重新设回其默认值，除非
-在补丁请求中显式地要求清除。对于默认值取决于其他字段的某些字段而言，
+在补丁请求中，已经设置了默认值的字段不会被重新设回其默认值，
+除非在补丁请求中显式地要求清除。对于默认值取决于其他字段的某些字段而言，
 这可能会引发一些意想不到的行为。当所依赖的其他字段后来发生改变时，
 基于它们所设置的默认值只能在显式执行清除操作时才会被更新。
 
@@ -1254,12 +1550,79 @@ by the server.
 
 **Example:**
 -->
-为此，建议在配置文件中为服务器设置默认值的字段显式提供定义，即使所
-给的定义与服务器端默认值设定相同。这样可以使得辩识无法被服务器重新
-基于默认值来设置的冲突字段变得容易。
+为此，建议在配置文件中为服务器设置默认值的字段显式提供定义，
+即使所给的定义与服务器端默认值设定相同。
+这样可以使得辩识无法被服务器重新基于默认值来设置的冲突字段变得容易。
 
 **示例：**
 
+<!--
+```yaml
+# last-applied-configuration
+spec:
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
+        ports:
+        - containerPort: 80
+
+# configuration file
+spec:
+  strategy:
+    type: Recreate # updated value
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
+        ports:
+        - containerPort: 80
+
+# live configuration
+spec:
+  strategy:
+    type: RollingUpdate # defaulted value
+    rollingUpdate: # defaulted value derived from type
+      maxSurge : 1
+      maxUnavailable: 1
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
+        ports:
+        - containerPort: 80
+
+# result after merge - ERROR!
+spec:
+  strategy:
+    type: Recreate # updated value: incompatible with rollingUpdate
+    rollingUpdate: # defaulted value: incompatible with "type: Recreate"
+      maxSurge : 1
+      maxUnavailable: 1
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: nginx
+        image: nginx:1.14.2
+        ports:
+        - containerPort: 80
+```
+-->
 ```yaml
 # last-applied-configuration
 spec:
@@ -1344,10 +1707,10 @@ spec:
 1. 用户创建 Deployment，未设置 `strategy.type`。
 2. 服务器为 `strategy.type` 设置默认值 `RollingUpdate`，并为 `strategy.rollingUpdate`
    设置默认值。
-3. 用户改变 `strategy.type` 为 `Recreate`。字段 `strategy.rollingUpdate` 仍会取其
-   默认设置值，尽管服务器期望该字段被清除。
-   如果 `strategy.rollingUpdate` 值最初于配置文件中定义，则它们需要被清除
-   这一点就更明确一些。
+3. 用户改变 `strategy.type` 为 `Recreate`。字段 `strategy.rollingUpdate`
+   仍会取其默认设置值，尽管服务器期望该字段被清除。
+   如果 `strategy.rollingUpdate` 值最初于配置文件中定义，
+   则它们需要被清除这一点就更明确一些。
 4. `apply` 操作失败，因为 `strategy.rollingUpdate` 未被清除。
    `strategy.rollingupdate` 在 `strategy.type` 为 `Recreate` 不可被设定。
 
@@ -1415,12 +1778,11 @@ an imperative writer requires manual steps:
 -->
 ### 将属主从配置文件改为直接指令式写者
 
-在 Kubernetes 1.5 中，将字段的属主从配置文件切换到某指令式写者需要手动
-执行以下步骤：
+在 Kubernetes 1.5 中，将字段的属主从配置文件切换到某指令式写者需要手动执行以下步骤：
 
 - 从配置文件中删除该字段；
-- 将字段从现时对象的 `kubectl.kubernetes.io/last-applied-configuration` 注解
-  中删除。
+- 将字段从现时对象的 `kubectl.kubernetes.io/last-applied-configuration`
+  注解中删除。
 
 <!--
 ## Changing management methods
@@ -1428,15 +1790,15 @@ an imperative writer requires manual steps:
 Kubernetes objects should be managed using only one method at a time.
 Switching from one method to another is possible, but is a manual process.
 -->
-## 更改管理方法  {#changing-management-methods} 
+## 更改管理方法  {#changing-management-methods}
 
 Kubernetes 对象在同一时刻应该只用一种方法来管理。
 从一种方法切换到另一种方法是可能的，但这一切换是一个手动过程。
 
+{{< note >}}
 <!--
 It is OK to use imperative deletion with declarative management.
 -->
-{{< note >}}
 在声明式管理方法中使用指令式命令来删除对象是可以的。
 {{< /note >}}
 
@@ -1457,26 +1819,15 @@ configuration involves several manual steps:
 ### 从指令式命令管理切换到声明式对象配置
 
 从指令式命令管理切换到声明式对象配置管理的切换包含以下几个手动步骤：
+
 <!--
 1. Export the live object to a local configuration file:
 
-     ```shell
-     kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
-     ```
+   ```shell
+   kubectl get <kind>/<name> -o yaml > <kind>_<name>.yaml
+   ```
 
-2. Manually remove the `status` field from the configuration file.
-
-    {{< note >}}
-    This step is optional, as `kubectl apply` does not update the status field even if it is present in the configuration file.
-    {{< /note >}}
-
-3. Set the `kubectl.kubernetes.io/last-applied-configuration` annotation on the object:
-
-    ```shell
-    kubectl replace --save-config -f <kind>_<name>.yaml
-    ```
-
-4. Change processes to use `kubectl apply` for managing the object exclusively.
+1. Manually remove the `status` field from the configuration file.
 -->
 1. 将现时对象导出到本地配置文件：
 
@@ -1487,15 +1838,29 @@ configuration involves several manual steps:
 2. 手动移除配置文件中的 `status` 字段。
 
    {{< note >}}
-   这一步骤是可选的，因为 `kubectl apply` 并不会更新 status 字段，即便
-   配置文件中包含 status 字段。
+   <!--
+   This step is optional, as `kubectl apply` does not update the status field
+   even if it is present in the configuration file.
+   -->
+   这一步骤是可选的，因为 `kubectl apply` 并不会更新 status 字段，
+   即便配置文件中包含 status 字段。
    {{< /note >}}
 
+<!--
+1. Set the `kubectl.kubernetes.io/last-applied-configuration` annotation on the object:
+
+   ```shell
+   kubectl replace --save-config -f <kind>_<name>.yaml
+   ```
+
+1. Change processes to use `kubectl apply` for managing the object exclusively.
+-->
 3. 设置对象上的 `kubectl.kubernetes.io/last-applied-configuration` 注解：
 
    ```shell
    kubectl replace --save-config -f <kind>_<name>.yaml
    ```
+
 4. 更改过程，使用 `kubectl apply` 专门管理对象。  
 
 {{< comment >}}
@@ -1507,15 +1872,15 @@ TODO(pwittrock): Why doesn't export remove the status field?  Seems like it shou
 
 1. Set the `kubectl.kubernetes.io/last-applied-configuration` annotation on the object:
 
-    ```shell
-    kubectl replace --save-config -f <kind>_<name>.yaml
-    ```
+   ```shell
+   kubectl replace --save-config -f <kind>_<name>.yaml
+   ```
 
 1. Change processes to use `kubectl apply` for managing the object exclusively.
 -->
 ### 从指令式对象配置切换到声明式对象配置
 
-1. 在对象上设置 `kubectl.kubernetes.io/last-applied-configuration` 注解： 
+1. 在对象上设置 `kubectl.kubernetes.io/last-applied-configuration` 注解：
 
     ```shell
     kubectl replace --save-config -f <kind>_<name>.yaml
@@ -1528,10 +1893,10 @@ TODO(pwittrock): Why doesn't export remove the status field?  Seems like it shou
 -->
 ## 定义控制器选择算符和 PodTemplate 标签
 
+{{< warning >}}
 <!--
 Updating selectors on controllers is strongly discouraged.
 -->
-{{< warning >}}
 强烈不建议更改控制器上的选择算符。
 {{< /warning >}}
 
@@ -1541,8 +1906,8 @@ used only by the controller selector with no other semantic meaning.
 
 **Example:**
 -->
-建议的方法是定义一个不可变更的 PodTemplate 标签，仅用于控制器选择算符且
-不包含其他语义性的含义。
+建议的方法是定义一个不可变更的 PodTemplate 标签，
+仅用于控制器选择算符且不包含其他语义性的含义。
 
 **示例：**
 
@@ -1568,4 +1933,3 @@ template:
 * [使用配置文件对 Kubernetes 对象执行指令式管理](/zh-cn/docs/tasks/manage-kubernetes-objects/imperative-config/)
 * [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/)
 * [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-