[zh] Resync concepts section (12)

content/zh/docs/concepts/containers/container-environment.md

@@ -68,6 +68,7 @@ Pod 定义中的用户所定义的环境变量也可在容器中使用，就像
 ### Cluster information
 
 A list of all services that were running when a Container was created is available to that Container as environment variables.
+This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services.
 Those environment variables match the syntax of Docker links.
 
 For a service named *foo* that maps to a Container named *bar*,
@@ -75,7 +76,9 @@ the following variables are defined:
 -->
 ### 集群信息
 
-创建容器时正在运行的所有服务的列表都可用作该容器的环境变量。这些环境变量与 Docker 链接的语法匹配。
+创建容器时正在运行的所有服务都可用作该容器的环境变量。
+这里的服务仅限于新容器的 Pod 所在的名字空间中的服务，以及 Kubernetes 控制面的服务。
+这些环境变量与 Docker 链接的语法相同。
 
 对于名为 *foo* 的服务，当映射到名为 *bar* 的容器时，以下变量是被定义了的：
 

content/zh/docs/concepts/containers/container-lifecycle-hooks.md

@@ -59,16 +59,21 @@ No parameters are passed to the handler.
 `PreStop`
 
 <!--
-This hook is called immediately before a container is terminated due to an API request or management event such as liveness probe failure, preemption, resource contention and others. A call to the preStop hook fails if the container is already in terminated or completed state.
-It is blocking, meaning it is synchronous,
-so it must complete before the signal to stop the container can be sent.
-No parameters are passed to the handler.
+This hook is called immediately before a container is terminated due to an API request or management
+event such as a liveness/startup probe failure, preemption, resource contention and others. A call
+to the `PreStop` hook fails if the container is already in a terminated or completed state and the
+hook must complete before the TERM signal to stop the container can be sent. The Pod's termination
+grace period countdown begins before the `PreStop` hook is executed, so regardless of the outcome of
+the handler, the container will eventually terminate within the Pod's termination grace period. No
+parameters are passed to the handler.
 -->
-在容器因 API 请求或者管理事件（诸如存活态探针失败、资源抢占、资源竞争等）而被终止之前，
-此回调会被调用。
-如果容器已经处于终止或者完成状态，则对 preStop 回调的调用将失败。
-此调用是阻塞的，也是同步调用，因此必须在发出删除容器的信号之前完成。
-没有参数传递给处理程序。
+在容器因 API 请求或者管理事件（诸如存活态探针、启动探针失败、资源抢占、资源竞争等）
+而被终止之前，此回调会被调用。
+如果容器已经处于已终止或者已完成状态，则对 preStop 回调的调用将失败。
+在用来停止容器的 TERM 信号被发出之前，回调必须执行结束。
+Pod 的终止宽限周期在 `PreStop` 回调被执行之前即开始计数，所以无论
+回调函数的执行结果如何，容器最终都会在 Pod 的终止宽限期内被终止。
+没有参数会被传递给处理程序。
 
 <!--
 A more detailed description of the termination behavior can be found in
@@ -122,6 +127,20 @@ the Container cannot reach a `running` state.
 但是，如果回调运行或挂起的时间太长，则容器无法达到 `running` 状态。
 
 <!--
+`PreStop` hooks are not executed asynchronously from the signal
+to stop the Container; the hook must complete its execution before
+the TERM signal can be sent.
+If a `PreStop` hook hangs during execution,
+the Pod's phase will be `Terminating` and remain there until the Pod is
+killed after its `terminationGracePeriodSeconds` expires.
+This grace period applies to the total time it takes for both
+the `PreStop` hook to execute and for the Container to stop normally.
+If, for example, `terminationGracePeriodSeconds` is 60, and the hook
+takes 55 seconds to complete, and the Container takes 10 seconds to stop
+normally after receiving the signal, then the Container will be killed
+before it can stop normally, since `terminationGracePeriodSeconds` is
+less than the total time (55+10) it takes for these two things to happen.
+
 `PreStop` hooks are not executed asynchronously from the signal
 to stop the Container; the hook must complete its execution before
 the signal can be sent.
@@ -145,7 +164,7 @@ less than the total time (55+10) it takes for these two things to happen.
 例如，如果 `terminationGracePeriodSeconds` 是 60，回调函数花了 55 秒钟
 完成执行，而容器在收到信号之后花了 10 秒钟来正常结束，那么容器会在其
 能够正常结束之前即被杀死，因为 `terminationGracePeriodSeconds` 的值
-小于后面两件事情所花费的总时间（55 + 10）。
+小于后面两件事情所花费的总时间（55+10）。
 
 <!--
 If either a `PostStart` or `PreStop` hook fails,

content/zh/docs/concepts/containers/images.md

@@ -89,30 +89,62 @@ Instead, specify a meaningful tag such as `v1.42.0`.
 <!--
 ## Updating images
 
-The default pull policy is `IfNotPresent` which causes the
-{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip
-pulling an image if it already exists. If you would like to always force a pull,
-you can do one of the following:
-
-- set the `imagePullPolicy` of the container to `Always`.
-- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use.
-- omit the `imagePullPolicy` and the tag for the image to use.
-- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
-
-When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
+When you first create a {{< glossary_tooltip text="Deployment" term_id="deployment" >}},
+{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}, Pod, or other
+object that includes a Pod template, then by default the pull policy of all
+containers in that pod will be set to `IfNotPresent` if it is not explicitly
+specified. This policy causes the
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip pulling an
+image if it already exists.
 -->
 ## 更新镜像  {#updating-images}
 
-默认的镜像拉取策略是 `IfNotPresent`：在镜像已经存在的情况下，
-{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 将不再去拉取镜像。
-如果希望强制总是拉取镜像，你可以执行以下操作之一：
+当你最初创建一个 {{< glossary_tooltip text="Deployment" term_id="deployment" >}}、
+{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}、Pod
+或者其他包含 Pod 模板的对象时，如果没有显式设定的话，Pod 中所有容器的默认镜像
+拉取策略是 `IfNotPresent`。这一策略会使得
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
+在镜像已经存在的情况下直接略过拉取镜像的操作。
+
+<!--
+If you would like to always force a pull, you can do one of the following:
+
+- set the `imagePullPolicy` of the container to `Always`.
+- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use;
+  Kubernetes will set the policy to `Always`.
+- omit the `imagePullPolicy` and the tag for the image to use.
+- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
+-->
+如果你希望强制总是拉取镜像，你可以执行以下操作之一：
 
 - 设置容器的 `imagePullPolicy` 为 `Always`。
-- 省略 `imagePullPolicy`，并使用 `:latest` 作为要使用的镜像的标签。
+- 省略 `imagePullPolicy`，并使用 `:latest` 作为要使用的镜像的标签；
+  Kubernetes 会将策略设置为 `Always`。
 - 省略 `imagePullPolicy` 和要使用的镜像标签。
 - 启用 [AlwaysPullImages](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)
   准入控制器（Admission Controller）。
 
+{{< note >}}
+<!--
+The value of `imagePullPolicy` of the container is always set when the object is
+first _created_, and is not updated if the image's tag later changes.
+
+For example, if you create a Deployment with an image whose tag is _not_
+`:latest`, and later update that Deployment's image to a `:latest` tag, the
+`imagePullPolicy` field will _not_ change to `Always`. You must manually change
+the pull policy of any object after its initial creation.
+-->
+对象被 *创建* 时，容器的 `imagePullPolicy` 总是被设置为某值，如果镜像的标签
+后来发生改变，镜像拉取策略也不会被改变。
+
+例如，如果你创建了一个 Deployment 对象，其中的镜像标签不是 `:latest`，
+后来 Deployment 的镜像被改为 `:latest`，则 `imagePullPolicy` 不会被改变为
+`Always`。你必须在对象被初始创建之后手动改变拉取策略。
+{{< /note >}}
+
+<!--
+When `imagePullPolicy` is defined without a specific value, it is also set to `Always`.
+-->
 如果 `imagePullPolicy` 未被定义为特定的值，也会被设置为 `Always`。
 
 <!--
@@ -245,7 +277,7 @@ example, run these on your desktop/laptop:
 
 <!--
 1. Run `docker login [server]` for each set of credentials you want to use.  This updates `$HOME/.docker/config.json` on your PC.
-1. View `$HOME/.docker/config.json` in an editor to ensure it contains just the credentials you want to use.
+1. View `$HOME/.docker/config.json` in an editor to ensure it contains only the credentials you want to use.
 1. Get a list of your nodes; for example:
       - if you want the names: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
       - if you want to get the IP addresses: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`

content/zh/docs/concepts/containers/runtime-class.md

@@ -1,5 +1,5 @@
 ---
-title: 容器运行时类(Runtime Class)
+title: 容器运行时类（Runtime Class）
 content_type: concept
 weight: 20
 ---
@@ -184,9 +184,11 @@ For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/
 #### dockershim
 
 <!--
-Kubernetes built-in dockershim CRI does not support runtime handlers.
+RuntimeClasses with dockershim must set the runtime handler to `docker`. Dockershim does not support
+custom configurable runtime handlers.
 -->
-Kubernetes 内置的 dockershim CRI 不支持配置运行时 handler。
+为 dockershim 设置 RuntimeClass 时，必须将运行时处理程序设置为 `docker`。
+Dockershim 不支持自定义的可配置的运行时处理程序。
 
 #### [containerd](https://containerd.io/)