diff --git a/content/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md b/content/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md
index e6f51807be3fa..bb3560efebc5d 100644
--- a/content/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md
+++ b/content/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md
@@ -241,7 +241,7 @@ The configuration is located under the `data.kubelet` key.
 To reflect the change on kubeadm nodes you must do the following:
 - Log in to a kubeadm node
 - Run `kubeadm upgrade node phase kubelet-config` to download the latest `kubelet-config`
-ConfigMap contents into the local file `/var/lib/kubelet/config.conf`
+ConfigMap contents into the local file `/var/lib/kubelet/config.yaml`
 - Edit the file `/var/lib/kubelet/kubeadm-flags.env` to apply additional configuration with
 flags
 - Restart the kubelet service with `systemctl restart kubelet`
@@ -252,7 +252,7 @@ flags
 
 - 登录到 kubeadm 节点
 - 运行 `kubeadm upgrade node phase kubelet-config` 下载最新的
-  `kubelet-config` ConfigMap 内容到本地文件 `/var/lib/kubelet/config.conf`
+  `kubelet-config` ConfigMap 内容到本地文件 `/var/lib/kubelet/config.yaml`
 - 编辑文件 `/var/lib/kubelet/kubeadm-flags.env` 以使用标志来应用额外的配置
 - 使用 `systemctl restart kubelet` 重启 kubelet 服务
 
@@ -266,15 +266,16 @@ Do these changes one node at a time to allow workloads to be rescheduled properl
 {{< note >}}
 <!--
 During `kubeadm upgrade`, kubeadm downloads the `KubeletConfiguration` from the
-`kubelet-config` ConfigMap and overwrite the contents of `/var/lib/kubelet/config.conf`.
+`kubelet-config` ConfigMap and overwrite the contents of `/var/lib/kubelet/config.yaml`.
 This means that node local configuration must be applied either by flags in
 `/var/lib/kubelet/kubeadm-flags.env` or by manually updating the contents of
-`/var/lib/kubelet/config.conf` after `kubeadm upgrade`, and then restarting the kubelet.
+`/var/lib/kubelet/config.yaml` after `kubeadm upgrade`, and then restarting the kubelet.
 -->
 在 `kubeadm upgrade` 期间，kubeadm 从 `kubelet-config` ConfigMap
-下载 `KubeletConfiguration` 并覆盖 `/var/lib/kubelet/config.conf` 的内容。
+下载 `KubeletConfiguration` 并覆盖 `/var/lib/kubelet/config.yaml` 的内容。
 这意味着节点本地配置必须通过`/var/lib/kubelet/kubeadm-flags.env`中的标志或在
-kubeadm upgrade` 后手动更新`/var/lib/kubelet/config.conf`的内容来应用，然后重新启动 kubelet。
+kubeadm upgrade` 后手动更新 `/var/lib/kubelet/config.yaml` 的内容来应用，
+然后重新启动 kubelet。
 {{< /note >}}
 
 <!--
@@ -488,26 +489,26 @@ the set of node specific patches must be updated accordingly.
 <!--
 #### Persisting kubelet reconfiguration
 
-Any changes to the `KubeletConfiguration` stored in `/var/lib/kubelet/config.conf` will be overwritten on
+Any changes to the `KubeletConfiguration` stored in `/var/lib/kubelet/config.yaml` will be overwritten on
 `kubeadm upgrade` by downloading the contents of the cluster wide `kubelet-config` ConfigMap.
-To persist kubelet node specific configuration either the file `/var/lib/kubelet/config.conf`
+To persist kubelet node specific configuration either the file `/var/lib/kubelet/config.yaml`
 has to be updated manually post-upgrade or the file `/var/lib/kubelet/kubeadm-flags.env` can include flags.
 The kubelet flags override the associated `KubeletConfiguration` options, but note that
 some of the flags are deprecated.
 
-A kubelet restart will be required after changing `/var/lib/kubelet/config.conf` or
+A kubelet restart will be required after changing `/var/lib/kubelet/config.yaml` or
 `/var/lib/kubelet/kubeadm-flags.env`.
 -->
 #### 持久化 kubelet 重新配置
 
-对存储在 `/var/lib/kubelet/config.conf` 中的 `KubeletConfiguration` 
+对存储在 `/var/lib/kubelet/config.yaml` 中的 `KubeletConfiguration` 
 所做的任何更改都将在 `kubeadm upgrade` 时因为下载集群范围内的 `kubelet-config`
 ConfigMap 的内容而被覆盖。
-要持久保存 kubelet 节点特定的配置，文件`/var/lib/kubelet/config.conf` 
-必须在升级后手动更新，或者文件`/var/lib/kubelet/kubeadm-flags.env` 可以包含标志。
+要持久保存 kubelet 节点特定的配置，文件 `/var/lib/kubelet/config.yaml` 
+必须在升级后手动更新，或者文件 `/var/lib/kubelet/kubeadm-flags.env` 可以包含标志。
 kubelet 标志会覆盖相关的 `KubeletConfiguration` 选项，但请注意，有些标志已被弃用。
 
-更改 `/var/lib/kubelet/config.conf` 或 `/var/lib/kubelet/kubeadm-flags.env` 
+更改 `/var/lib/kubelet/config.yaml` 或 `/var/lib/kubelet/kubeadm-flags.env` 
 后需要重启 kubelet。
 
 
diff --git a/content/zh-cn/docs/tasks/administer-cluster/topology-manager.md b/content/zh-cn/docs/tasks/administer-cluster/topology-manager.md
index f25486108eaa4..7f5d083f4a6a0 100644
--- a/content/zh-cn/docs/tasks/administer-cluster/topology-manager.md
+++ b/content/zh-cn/docs/tasks/administer-cluster/topology-manager.md
@@ -349,10 +349,10 @@ kubelet 将调用每个建议提供者以确定资源可用性。
 如果亲和性不是首选，则拓扑管理器将存储该亲和性，并且无论如何都将 Pod 接纳到该节点。
 
 <!--
-The *Hint Providers* can then use this information when making the 
+The *Hint Providers* can then use this information when making the
 resource allocation decision.
 -->
-之后 **建议提供者** 可以在进行资源分配决策时使用这个信息。
+之后**建议提供者**可以在进行资源分配决策时使用这个信息。
 
 <!--
 ### restricted policy {#policy-restricted}
@@ -382,10 +382,10 @@ have the `Topology Affinity` error.
 还可以通过实现外部控制环，以触发重新部署具有 `Topology Affinity` 错误的 Pod。
 
 <!--
-If the pod is admitted, the *Hint Providers* can then use this information when making the 
+If the pod is admitted, the *Hint Providers* can then use this information when making the
 resource allocation decision.
 -->
-如果 Pod 被允许运行在某节点，则 **建议提供者** 可以在做出资源分配决定时使用此信息。
+如果 Pod 被允许运行在某节点，则**建议提供者**可以在做出资源分配决定时使用此信息。
 
 <!--
 ### single-numa-node policy {#policy-single-numa-node}
@@ -421,30 +421,38 @@ that have the `Topology Affinity` error.
 ### Topology manager policy options
 
 Support for the Topology Manager policy options requires `TopologyManagerPolicyOptions`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled
+(it is enabled by default).
 -->
 ### 拓扑管理器策略选项  {#topology-manager-policy-options}
 
 对拓扑管理器策略选项的支持需要启用 `TopologyManagerPolicyOptions`
-[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)（默认启用）。
 
 <!--
 You can toggle groups of options on and off based upon their maturity level using the following feature gates:
-* `TopologyManagerPolicyBetaOptions` default disabled. Enable to show beta-level options. Currently there are no beta-level options.
-* `TopologyManagerPolicyAlphaOptions` default disabled. Enable to show alpha-level options. You will still have to enable each option using the `TopologyManagerPolicyOptions` kubelet option.
+* `TopologyManagerPolicyBetaOptions` default enabled.. Enable to show beta-level options.
+* `TopologyManagerPolicyAlphaOptions` default disabled. Enable to show alpha-level options.
 -->
 你可以使用以下特性门控根据成熟度级别打开和关闭这些选项组：
-* `TopologyManagerPolicyBetaOptions` 默认禁用。启用以显示 Beta 级别选项。目前没有 Beta 级别选项。
-* `TopologyManagerPolicyAlphaOptions` 默认禁用。启用以显示 Alpha 级别选项。你仍然需要使用
-  `TopologyManagerPolicyOptions` kubelet 选项来启用每个选项。
+* `TopologyManagerPolicyBetaOptions` 默认启用。启用以显示 Beta 级别选项。
+* `TopologyManagerPolicyAlphaOptions` 默认禁用。启用以显示 Alpha 级别选项。
+
+<!--
+You will still have to enable each option using the `TopologyManagerPolicyOptions` kubelet option.
+-->
+你仍然需要使用 `TopologyManagerPolicyOptions` kubelet 选项来启用每个选项。
 
 <!--
 The following policy options exists:
-* `prefer-closest-numa-nodes` (alpha, invisible by default, `TopologyManagerPolicyOptions` and `TopologyManagerPolicyAlphaOptions` feature gates have to be enabled)(1.26 or higher)
+* `prefer-closest-numa-nodes` (beta, visible by default, `TopologyManagerPolicyOptions` and `TopologyManagerPolicyAlphaOptions` feature gates have to be enabled).
+The `prefer-closest-numa-nodes` policy option is beta in Kubernetes {{< skew currentVersion >}}.
 -->
 存在以下策略选项：
-* `prefer-closest-numa-nodes`（Alpha，默认不可见，`TopologyManagerPolicyOptions` 和
-  `TopologyManagerPolicyAlphaOptions` 特性门控必须被启用）（1.26 或更高版本）
+* `prefer-closest-numa-nodes`（Beta，默认可见，`TopologyManagerPolicyOptions` 和
+  `TopologyManagerPolicyAlphaOptions` 特性门控必须被启用）。
+  `prefer-closest-numa-nodes` 策略选项在 Kubernetes {{< skew currentVersion >}}
+  中是 Beta 版。
 
 <!--
 If the `prefer-closest-numa-nodes` policy option is specified, the `best-effort` and `restricted`
@@ -580,7 +588,7 @@ This pod runs in the `BestEffort` QoS class because there are no CPU and memory
 
 <!--
 The Topology Manager would consider the above pods. The Topology Manager would consult the Hint
-Providers, which are CPU and Device Manager to get topology hints for the pods. 
+Providers, which are CPU and Device Manager to get topology hints for the pods.
 
 In the case of the `Guaranteed` pod with integer CPU request, the `static` CPU Manager policy
 would return topology hints relating to the exclusive CPU and the Device Manager would send back
@@ -615,7 +623,7 @@ of the requested devices.
 <!--
 Using this information the Topology Manager calculates the optimal hint for the pod and stores
 this information, which will be used by the Hint Providers when they are making their resource
-assignments. 
+assignments.
 -->
 基于此信息，拓扑管理器将为 Pod 计算最佳提示并存储该信息，并且供
 提示提供程序在进行资源分配时使用。
@@ -636,4 +644,3 @@ assignments.
 1. 拓扑管理器所能处理的最大 NUMA 节点个数是 8。若 NUMA 节点数超过 8，
    枚举可能的 NUMA 亲和性并为之生成提示时会发生状态爆炸。
 2. 调度器无法感知拓扑，所以有可能一个 Pod 被调度到一个节点之后，会因为拓扑管理器的缘故在该节点上启动失败。
-
diff --git a/content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
index ddcec67f6c121..e965f3b50fe71 100644
--- a/content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+++ b/content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
@@ -330,7 +330,7 @@ can't it is considered a failure.
 <!--
 As you can see, configuration for a TCP check is quite similar to an HTTP check.
 This example uses both readiness and liveness probes. The kubelet will send the
-first readiness probe 5 seconds after the container starts. This will attempt to
+first readiness probe 15 seconds after the container starts. This will attempt to
 connect to the `goproxy` container on port 8080. If the probe succeeds, the Pod
 will be marked as ready. The kubelet will continue to run this check every 10
 seconds.
@@ -344,7 +344,7 @@ will be restarted.
 To try the TCP liveness check, create a Pod:
 -->
 如你所见，TCP 检测的配置和 HTTP 检测非常相似。
-下面这个例子同时使用就绪和存活探针。kubelet 会在容器启动 5 秒后发送第一个就绪探针。
+下面这个例子同时使用就绪和存活探针。kubelet 会在容器启动 15 秒后发送第一个就绪探针。
 探针会尝试连接 `goproxy` 容器的 8080 端口。
 如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次探测。
 
@@ -635,8 +635,9 @@ liveness and readiness checks:
 <!--
 * `initialDelaySeconds`: Number of seconds after the container has started before startup,
   liveness or readiness probes are initiated. If a startup  probe is defined, liveness and
-  readiness probe delays do not begin until the startup probe has succeeded.
-  Defaults to 0 seconds. Minimum value is 0.
+  readiness probe delays do not begin until the startup probe has succeeded. If the value of
+  `periodSeconds` is greater than `initialDelaySeconds` then the `initialDelaySeconds` would be
+  ignored. Defaults to 0 seconds. Minimum value is 0.
 * `periodSeconds`: How often (in seconds) to perform the probe. Default to 10 seconds.
   The minimum value is 1.
 * `timeoutSeconds`: Number of seconds after which the probe times out.
@@ -647,7 +648,8 @@ liveness and readiness checks:
 -->
 * `initialDelaySeconds`：容器启动后要等待多少秒后才启动启动、存活和就绪探针。
   如果定义了启动探针，则存活探针和就绪探针的延迟将在启动探针已成功之后才开始计算。
-  默认是 0 秒，最小值是 0。
+  如果 `periodSeconds` 的值大于 `initialDelaySeconds`，则 `initialDelaySeconds`
+  将被忽略。默认是 0 秒，最小值是 0。
 * `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。
 * `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
 * `successThreshold`：探针在失败后，被视为成功的最小连续成功数。默认值是 1。
diff --git a/content/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md b/content/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
index 19bd491ddba15..22896e2338111 100644
--- a/content/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
+++ b/content/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md
@@ -82,13 +82,23 @@ Save the file as `Dockerfile`, build the image and push it to a registry. This e
 pushes the image to
 [Google Container Registry (GCR)](https://cloud.google.com/container-registry/).
 For more details, please read the GCR
-[documentation](https://cloud.google.com/container-registry/docs/).
+[documentation](https://cloud.google.com/container-registry/docs/). Alternatively
+you can also use the [docker hub](https://hub.docker.com/search?q=). For more details
+refer to the docker hub [documentation](https://docs.docker.com/docker-hub/repos/create/#create-a-repository).
 -->
 将文件保存为 `Dockerfile`，构建镜像并将其推送到镜像仓库。
 此示例将镜像推送到 [Google 容器镜像仓库（GCR）](https://cloud.google.com/container-registry/)。
 有关详细信息，请阅读 GCR [文档](https://cloud.google.com/container-registry/docs/)。
+或者，你也可以使用 [Docker Hub](https://hub.docker.com/search?q=)。
+有关更多详细信息，请参阅 Docker Hub
+[文档](https://docs.docker.com/docker-hub/repos/create/#create-a-repository)。
 
+<!--
+# The image name and the repository
+# used in here is just an example
+-->
 ```shell
+# 这里使用的镜像名称和仓库只是一个例子
 docker build -t gcr.io/my-gcp-project/my-kube-scheduler:1.0 .
 gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0
 ```
@@ -326,7 +336,7 @@ scheduler in that pod spec. Let's look at three examples.
 <!--
   Verify that all three pods are running.
 -->
-  确认所有三个 pod 都在运行。
+  确认所有三个 Pod 都在运行。
 
   ```shell
   kubectl get pods
@@ -337,7 +347,7 @@ scheduler in that pod spec. Let's look at three examples.
 <!--
 ### Verifying that the pods were scheduled using the desired schedulers
 -->
-### 验证是否使用所需的调度器调度了 pod
+### 验证是否使用所需的调度器调度了 Pod
 
 <!--
 In order to make it easier to work through these examples, we did not verify that the
@@ -352,15 +362,15 @@ scheduled as well.
 为了更容易地完成这些示例，我们没有验证 Pod 实际上是使用所需的调度程序调度的。
 我们可以通过更改 Pod 的顺序和上面的部署配置提交来验证这一点。
 如果我们在提交调度器部署配置之前将所有 Pod 配置提交给 Kubernetes 集群，
-我们将看到注解了 `annotation-second-scheduler` 的 Pod 始终处于 “Pending” 状态，
+我们将看到注解了 `annotation-second-scheduler` 的 Pod 始终处于 `Pending` 状态，
 而其他两个 Pod 被调度。
 一旦我们提交调度器部署配置并且我们的新调度器开始运行，注解了
-`annotation-second-scheduler` 的 pod 就能被调度。
+`annotation-second-scheduler` 的 Pod 就能被调度。
 <!--
 Alternatively, you can look at the "Scheduled" entries in the event logs to
 verify that the pods were scheduled by the desired schedulers.
 -->
-或者，可以查看事件日志中的 “Scheduled” 条目，以验证是否由所需的调度器调度了 Pod。
+或者，可以查看事件日志中的 `Scheduled` 条目，以验证是否由所需的调度器调度了 Pod。
 
 ```shell
 kubectl get events
@@ -372,5 +382,4 @@ or a custom container image for the cluster's main scheduler by modifying its st
 on the relevant control plane nodes.
 -->
 你也可以使用[自定义调度器配置](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)
-或自定义容器镜像，用于集群的主调度器，方法是在相关控制平面节点上修改其静态 pod 清单。
-
+或自定义容器镜像，用于集群的主调度器，方法是在相关控制平面节点上修改其静态 Pod 清单。