Merge pull request #40046 from howieyuen/concept-4

[zh-cn] sync concepts files of workloads

content/zh-cn/docs/concepts/workloads/_index.md

@@ -1,12 +1,12 @@
 ---
 title: "工作负载"
-weight: 50
+weight: 55
 description: 理解 Pods，Kubernetes 中可部署的最小计算对象，以及辅助它运行它们的高层抽象对象。
 ---
 
 <!--
 title: "Workloads"
-weight: 50
+weight: 55
 description: >
   Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them.
 no_list: true

content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md

@@ -398,7 +398,7 @@ That is, the CronJob does _not_ update existing Jobs, even if those remain runni
 A CronJob creates a Job object approximately once per execution time of its schedule.
 The scheduling is approximate because there
 are certain circumstances where two Jobs might be created, or no Job might be created.
-Kubernetes tries to avoid those situations, but do not completely prevent them. Therefore,
+Kubernetes tries to avoid those situations, but does not completely prevent them. Therefore,
 the Jobs that you define should be _idempotent_.
 -->
 ### Job 创建  {#job-creation}

content/zh-cn/docs/concepts/workloads/controllers/job.md

@@ -1353,7 +1353,7 @@ These are some requirements and semantics of the API:
   are evaluated in order. Once a rule matches a Pod failure, the remaining rules
   are ignored. When no rule matches the Pod failure, the default
   handling applies.
-- you may want to restrict a rule to a specific container by specifing its name
+- you may want to restrict a rule to a specific container by specifying its name
   in`spec.podFailurePolicy.rules[*].containerName`. When not specified the rule
   applies to all containers. When specified, it should match one the container
   or `initContainer` names in the Pod template.

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

@@ -555,14 +555,14 @@ Pod 中的所有容器都可以在特权模式下运行，以使用原本无法
 此模式同时适用于 Windows 和 Linux。
 
 <!--
-### Linux priviledged containers
+### Linux privileged containers
 
 In Linux, any container in a Pod can enable privileged mode using the `privileged` (Linux) flag
 on the [security context](/docs/tasks/configure-pod-container/security-context/) of the
 container spec. This is useful for containers that want to use operating system administrative
 capabilities such as manipulating the network stack or accessing hardware devices.
 -->
-### Linux 特权容器   {#linux-priviledged-containers}
+### Linux 特权容器   {#linux-privileged-containers}
 
 在 Linux 中，Pod 中的所有容器都可以使用容器规约中的
 [安全性上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)中的
@@ -570,9 +570,9 @@ capabilities such as manipulating the network stack or accessing hardware device
 这对于想要使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问硬件设备）的容器很有用。
 
 <!--
-### Windows priviledged containers
+### Windows privileged containers
 -->
-### Windows 特权容器   {#windows-priviledged-containers}
+### Windows 特权容器   {#windows-privileged-containers}
 
 {{< feature-state for_k8s_version="v1.26" state="stable" >}}
 

content/zh-cn/docs/concepts/workloads/pods/user-namespaces.md

@@ -16,7 +16,7 @@ min-kubernetes-server-version: v1.25
 {{< feature-state for_k8s_version="v1.25" state="alpha" >}}
 <!--
 This page explains how user namespaces are used in Kubernetes pods. A user
-namespace allows to isolate the user running inside the container from the one
+namespace isolates the user running inside the container from the one
 in the host.
 
 A process running as root in a container can run as a different (non-root) user
@@ -24,8 +24,8 @@ in the host; in other words, the process has full privileges for operations
 inside the user namespace, but is unprivileged for operations outside the
 namespace.
 -->
-本页解释了在 Kubernetes pods 中如何使用用户命名空间。
+本页解释了在 Kubernetes Pod 中如何使用用户命名空间。
-用户命名空间允许将容器内运行的用户与主机内的用户隔离开来。
+用户命名空间将容器内运行的用户与主机中的用户隔离开来。
 
 在容器中以 root 身份运行的进程可以在主机中以不同的（非 root）用户身份运行；
 换句话说，该进程在用户命名空间内的操作具有完全的权限，