Merge pull request #43221 from qlijin/sync_pods

[zh-cn] sync concepts/workloads/pods/*

Author: k8s-ci-robot

content/zh-cn/docs/concepts/workloads/pods/init-containers.md

@@ -87,7 +87,7 @@ Init 容器的状态在 `status.initContainerStatuses` 字段中以容器状态
 Init containers support all the fields and features of app containers,
 including resource limits, [volumes](/docs/concepts/storage/volumes/), and security settings. However, the
 resource requests and limits for an init container are handled differently,
-as documented in [Resources](#resources).
+as documented in [Resource sharing within containers](#resource-sharing-within-containers).
 
 Also, init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or
 `startupProbe` because they must run to completion before the Pod can be ready.
@@ -101,7 +101,8 @@ the application containers for the Pod and runs them as usual.
 
 Init 容器支持应用容器的全部字段和特性，包括资源限制、
 [数据卷](/zh-cn/docs/concepts/storage/volumes/)和安全设置。
-然而，Init 容器对资源请求和限制的处理稍有不同，在下面[资源](#resources)节有说明。
+然而，Init 容器对资源请求和限制的处理稍有不同，
+在下面[容器内的资源共享](#resource-sharing-within-containers)节有说明。
 
 同时 Init 容器不支持 `lifecycle`、`livenessProbe`、`readinessProbe` 和 `startupProbe`，
 因为它们必须在 Pod 就绪之前运行完成。

content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -327,7 +327,7 @@ Kubelet 管理以下 PodCondition：
 
 <!--
 * `PodScheduled`: the Pod has been scheduled to a node.
-* `PodHasNetwork`: (alpha feature; must be [enabled explicitly](#pod-has-network)) the
+* `PodReadyToStartContainers`: (alpha feature; must be [enabled explicitly](#pod-has-network)) the
   Pod sandbox has been successfully created and networking configured.
 * `ContainersReady`: all containers in the Pod are ready.
 * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/)
@@ -336,7 +336,7 @@ Kubelet 管理以下 PodCondition：
   balancing pools of all matching Services.
 -->
 * `PodScheduled`：Pod 已经被调度到某节点；
-* `PodHasNetwork`：Pod 沙箱被成功创建并且配置了网络（Alpha 特性，必须被[显式启用](#pod-has-network)）；
+* `PodReadyToStartContainers`：Pod 沙箱被成功创建并且配置了网络（Alpha 特性，必须被[显式启用](#pod-has-network)）；
 * `ContainersReady`：Pod 中所有容器都已就绪；
 * `Initialized`：所有的 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)都已成功完成；
 * `Ready`：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。
@@ -462,29 +462,36 @@ When a Pod's containers are Ready but at least one custom condition is missing o
 
 {{< feature-state for_k8s_version="v1.25" state="alpha" >}}
 
+{{< note >}}
+<!--
+This condition was renamed from PodHasNetwork to PodReadyToStartContainers.
+-->
+这种状况已从 PodHasNetwork 重命名为 PodReadyToStartContainers。
+{{< /note >}}
+
 <!--
 After a Pod gets scheduled on a node, it needs to be admitted by the Kubelet and
 have any volumes mounted. Once these phases are complete, the Kubelet works with
 a container runtime (using {{< glossary_tooltip term_id="cri" >}}) to set up a
-runtime sandbox and configure networking for the Pod. If the `PodHasNetworkCondition`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
-Kubelet reports whether a Pod has reached this initialization milestone through
-the `PodHasNetwork` condition in the `status.conditions` field of a Pod.
+runtime sandbox and configure networking for the Pod. If the
+`PodReadyToStartContainersCondition` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
+Kubelet reports whether a pod has reached this initialization milestone through
+the `PodReadyToStartContainers` condition in the `status.conditions` field of a Pod.
 -->
 在 Pod 被调度到某节点后，它需要被 Kubelet 接受并且挂载所需的卷。
 一旦这些阶段完成，Kubelet 将与容器运行时（使用{{< glossary_tooltip term_id="cri" >}}）
-一起为 Pod 生成运行时沙箱并配置网络。如果启用了
-`PodHasNetworkCondition` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
-kubelet 会通过 Pod 的 `status.conditions` 字段中的 `PodHasNetwork` 状况来报告
+一起为 Pod 生成运行时沙箱并配置网络。如果启用了 `PodReadyToStartContainersCondition` 
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
+kubelet 会通过 Pod 的 `status.conditions` 字段中的 `PodReadyToStartContainers` 状况来报告
 Pod 是否达到了初始化里程碑。
 
 <!--
-The `PodHasNetwork` condition is set to `False` by the Kubelet when it detects a
+The `PodReadyToStartContainers` condition is set to `False` by the Kubelet when it detects a
 Pod does not have a runtime sandbox with networking configured. This occurs in
 the following scenarios:
 -->
-当 kubelet 检测到 Pod 不具备配置了网络的运行时沙箱时，`PodHasNetwork` 状况将被设置为 `False`。
-以下场景中将会发生这种状况：
+当 kubelet 检测到 Pod 不具备配置了网络的运行时沙箱时，`PodReadyToStartContainers`
+状况将被设置为 `False`。以下场景中将会发生这种状况：
 
 <!--
 - Early in the lifecycle of the Pod, when the kubelet has not yet begun to set up a sandbox for
@@ -501,14 +508,14 @@ the following scenarios:
   * 对于使用虚拟机进行隔离的容器运行时，Pod 沙箱虚拟机重启时，需要创建一个新的沙箱和全新的容器网络配置。
 
 <!--
-The `PodHasNetwork` condition is set to `True` by the kubelet after the
+The `PodReadyToStartContainers` condition is set to `True` by the kubelet after the
 successful completion of sandbox creation and network configuration for the Pod
 by the runtime plugin. The kubelet can start pulling container images and create
-containers after `PodHasNetwork` condition has been set to `True`.
+containers after `PodReadyToStartContainers` condition has been set to `True`.
 -->
 在运行时插件成功完成 Pod 的沙箱创建和网络配置后，
-kubelet 会将 `PodHasNetwork` 状况设置为 `True`。
-当 `PodHasNetwork` 状况设置为 `True` 后，
+kubelet 会将 `PodReadyToStartContainers` 状况设置为 `True`。
+当 `PodReadyToStartContainers` 状况设置为 `True` 后，
 Kubelet 可以开始拉取容器镜像和创建容器。
 
 <!--
@@ -831,16 +838,18 @@ shutdown.
 Pod。
 
 <!--
-Typically, the container runtime sends a TERM signal to the main process in each
-container. Many container runtimes respect the `STOPSIGNAL` value defined in the container
-image and send this instead of TERM.
-Once the grace period has expired, the KILL signal is sent to any remaining processes, and the Pod
-is then deleted from the {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}.
-If the kubelet or the container runtime's management service is restarted while waiting for
-processes to terminate, the cluster retries from the start including the full original grace period.
+Typically, with this graceful termination of the pod, kubelet makes requests to the container runtime to attempt to stop the containers in the pod by first sending a TERM (aka. SIGTERM) signal, with a grace period timeout, to the main process in each container. The requests to stop the containers are processed by the container runtime asynchronously. There is no guarantee to the order of processing for these requests. Many container runtimes respect the `STOPSIGNAL` value defined in the container image and, if different, send the container image configured STOPSIGNAL instead of TERM.
+Once the grace period has expired, the KILL signal is sent to any remaining
+processes, and the Pod is then deleted from the
+{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}. If the kubelet or the
+container runtime's management service is restarted while waiting for processes to terminate, the
+cluster retries from the start including the full original grace period.
 -->
-通常情况下，容器运行时会发送一个 TERM 信号到每个容器中的主进程。
-很多容器运行时都能够注意到容器镜像中 `STOPSIGNAL` 的值，并发送该信号而不是 TERM。
+通常 Pod 体面终止的过程为：kubelet 先发送一个带有体面超时限期的 TERM（又名 SIGTERM）
+信号到每个容器中的主进程，将请求发送到容器运行时来尝试停止 Pod 中的容器。
+停止容器的这些请求由容器运行时以异步方式处理。
+这些请求的处理顺序无法被保证。许多容器运行时遵循容器镜像内定义的 `STOPSIGNAL` 值，
+如果不同，则发送容器镜像中配置的 STOPSIGNAL，而不是 TERM 信号。
 一旦超出了体面终止限期，容器运行时会向所有剩余进程发送 KILL 信号，之后
 Pod 就会被从 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}上移除。
 如果 `kubelet` 或者容器运行时的管理服务在等待进程终止期间被重启，

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

@@ -83,18 +83,18 @@ tmpfs、overlayfs。
 <!--
 In addition, support is needed in the
 {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
-to use this feature with Kubernetes stateless pods:
+to use this feature with Kubernetes pods:
 
 * CRI-O: version 1.25 (and later) supports user namespaces for containers.
 -->
 
 此外，需要在{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}提供支持，
-才能在 Kubernetes 无状态 Pod 中使用这一功能：
+才能在 Kubernetes Pod 中使用这一功能：
 
 * CRI-O：1.25（及更高）版本支持配置容器的用户命名空间。
 
 <!--
-containerd v1.7 is not compatible with the userns support in Kubernetes v{{< skew currentVersion >}}.
+containerd v1.7 is not compatible with the userns support in Kubernetes v1.27 to v{{< skew latestVersion >}}.
 Kubernetes v1.25 and v1.26 used an earlier implementation that **is** compatible with containerd v1.7,
 in terms of userns support.
 If you are using a version of Kubernetes other than {{< skew currentVersion >}},
@@ -105,7 +105,8 @@ documentation for compatibility information.
 You can see the status of user namespaces support in cri-dockerd tracked in an [issue][CRI-dockerd-issue]
 on GitHub.
 -->
-containerd v1.7 与 Kubernetes v{{< skew currentVersion >}} 中的用户命名空间不兼容。
+containerd v1.7 与 Kubernetes v1.27 至 v{{< skew currentVersion >}}
+版本中的用户命名空间不兼容。
 Kubernetes v1.25 和 v1.26 使用了早期的实现，在用户命名空间方面与 containerd v1.7 兼容。
 如果你使用的 Kubernetes 版本不是 {{< skew currentVersion >}}，请查看该版本 Kubernetes
 的文档以获取更准确的信息。
@@ -134,7 +135,7 @@ to `false`.
 
 <!--
 The kubelet will pick host UIDs/GIDs a pod is mapped to, and will do so in a way
-to guarantee that no two stateless pods on the same node use the same mapping.
+to guarantee that no two pods on the same node use the same mapping.
 
 The `runAsUser`, `runAsGroup`, `fsGroup`, etc. fields in the `pod.spec` always
 refer to the user inside the container.
@@ -143,7 +144,7 @@ The valid UIDs/GIDs when this feature is enabled is the range 0-65535. This
 applies to files and processes (`runAsUser`, `runAsGroup`, etc.).
 -->
 kubelet 将挑选 Pod 所映射的主机 UID/GID，
-并将以保证同一节点上没有两个无状态 Pod 使用相同的映射的方式进行。
+并以此保证同一节点上没有两个 Pod 使用相同的方式进行映射。
 
 `pod.spec` 中的 `runAsUser`、`runAsGroup`、`fsGroup` 等字段总是指的是容器内的用户。
 启用该功能时，有效的 UID/GID 在 0-65535 范围内。这以限制适用于文件和进程（`runAsUser`、`runAsGroup` 等）。
@@ -166,9 +167,9 @@ if user namespaces is activated.
 在用户命名空间被启用时，应该可以继续正常运行，不需要做任何改变。
 
 <!--
-## Understanding user namespaces for stateless pods
+## Understanding user namespaces for pods {#pods-and-userns}
 -->
-## 了解无状态 Pod 的用户命名空间 {#understanding-user-namespaces-for-stateless-pods}
+## 了解 Pod 的用户命名空间 {#pods-and-userns}
 
 <!--
 Several container runtimes with their default configuration (like Docker Engine,
@@ -299,25 +300,6 @@ allowed to set any of:
 * `hostIPC: true`
 * `hostPID: true`
 
-<!--
-The pod is allowed to use no volumes at all or, if using volumes, only these
-volume types are allowed:
-
- * configmap
- * secret
- * projected
- * downwardAPI
- * emptyDir
--->
-
-Pod 完全不使用卷是被允许的；如果使用卷，只允许使用以下卷类型：
-
-* configmap
-* secret
-* projected
-* downwardAPI
-* emptyDir
-
 ## {{% heading "whatsnext" %}}
 
 <!--