Merge pull request #35718 from hs0210/sync-commented-en-txt

[zh-cn] resync: some file's commented English texts under docks/tasks

content/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md

@@ -259,7 +259,7 @@ The `kubelet-stats` monitor was previously deprecated by the vendor, in favor of
 The `docker-container-stats` monitor is the one affected by dockershim removal.
 Do not use the `docker-container-stats` with container runtimes other than Docker Engine.
 
-How to migrate from dockershim-dependant agent:
+How to migrate from dockershim-dependent agent:
 1. Remove `docker-container-stats` from the list of [configured monitors](https://github.com/signalfx/signalfx-agent/blob/main/docs/monitor-config.md).
    Note, keeping this monitor enabled with non-dockershim runtime will result in incorrect metrics
    being reported when docker is installed on node and no metrics when docker is not installed.

content/zh-cn/docs/tasks/administer-cluster/nodelocaldns.md

@@ -6,7 +6,7 @@ content_type: task
 reviewers:
 - bowei
 - zihongz
-title: Using NodeLocal DNSCache in Kubernetes clusters
+title: Using NodeLocal DNSCache in Kubernetes Clusters
 content_type: task
 -->
 
@@ -70,7 +70,7 @@ NodeLocal DNSCache 通过在集群节点上作为 DaemonSet 运行 DNS 缓存代
   并避免 UDP DNS 条目填满 conntrack 表。
 
 <!--
-* Connections from local caching agent to kube-dns service can be upgraded to TCP.
+* Connections from the local caching agent to kube-dns service can be upgraded to TCP.
   TCP conntrack entries will be removed on connection close in contrast with
   UDP entries that have to timeout
   ([default](https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt)
@@ -96,7 +96,7 @@ NodeLocal DNSCache 通过在集群节点上作为 DaemonSet 运行 DNS 缓存代
 * 在节点级别对 DNS 请求的度量和可见性。
 
 <!--
-* Negative caching can be re-enabled, thereby reducing number of queries to kube-dns service.
+* Negative caching can be re-enabled, thereby reducing the number of queries for the kube-dns service.
 -->
 * 可以重新启用负缓存，从而减少对 kube-dns 服务的查询数量。
 
@@ -124,7 +124,7 @@ This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
 {{< note >}}
 The local listen IP address for NodeLocal DNSCache can be any address that
 can be guaranteed to not collide with any existing IP in your cluster.
-It's recommended to use an address with a local scope, per example,
+It's recommended to use an address with a local scope, for example,
 from the 'link-local' range '169.254.0.0/16' for IPv4 or from the
 'Unique Local Address' range in IPv6 'fd00::/8'.
 {{< /note >}}
@@ -149,9 +149,9 @@ This feature can be enabled using the following steps:
   准备一个清单，把它保存为 `nodelocaldns.yaml`。
 
 <!--
-* If using IPv6, the CoreDNS configuration file need to enclose all the IPv6 addresses
+* If using IPv6, the CoreDNS configuration file needs to enclose all the IPv6 addresses
   into square brackets if used in 'IP:Port' format.
-  If you are using the sample manifest from the previous point, this will require to modify
+  If you are using the sample manifest from the previous point, this will require you to modify
   [the configuration line L70](https://github.com/kubernetes/kubernetes/blob/b2ecd1b3a3192fbbe2b9e348e095326f51dc43dd/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml#L70)
   like this: "`health [__PILLAR__LOCAL__DNS__]:8080`"
 -->
@@ -193,7 +193,7 @@ This feature can be enabled using the following steps:
     `__PILLAR__CLUSTER__DNS__` and `__PILLAR__UPSTREAM__SERVERS__` will be populated by
     the `node-local-dns` pods.
     In this mode, the `node-local-dns` pods listen on both the kube-dns service IP
-    as well as `<node-local-address>`, so pods can lookup DNS records using either IP address.
+    as well as `<node-local-address>`, so pods can look up DNS records using either IP address.
 -->
   * 如果 kube-proxy 运行在 IPTABLES 模式：
 

content/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp.md

@@ -633,7 +633,7 @@ configuration of the API server:
 <!--
 To verify that the PodSecurityPolicy admission controller is no longer enabled, you can manually run
 a test by impersonating a user without access to any PodSecurityPolicies (see the
-[PodSecurityPolicy example](/docs/concepts/policy/pod-security-policy/#example)), or by verifying in
+[PodSecurityPolicy example](/docs/concepts/security/pod-security-policy/#example)), or by verifying in
 the API server logs. At startup, the API server outputs log lines listing the loaded admission
 controller plugins:
 -->

content/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs.md

@@ -218,7 +218,7 @@ For more information about working with Kubernetes objects and their
 {{< glossary_tooltip text="manifests" term_id="manifest" >}}, see the
 [managing resources](/docs/concepts/cluster-administration/manage-deployment/),
 and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents.
-Each manifest for a CrobJob also needs a [`.spec`](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status) section.
+Each manifest for a CronJob also needs a [`.spec`](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status) section.
 
 -->
 ## 编写 CronJob 声明信息 {#writing-a-cronjob-spec}