Merge pull request #28020 from CaoDonghui123/fix1

[zh]Resync tasks files[8]

Author: k8s-ci-robot

content/zh/docs/tasks/configure-pod-container/assign-cpu-resource.md

@@ -166,9 +166,9 @@ kubectl top pod cpu-demo --namespace=cpu-example
 
 <!-- 
 This example output shows that the Pod is using 974 milliCPU, which is
-just a bit less than the limit of 1 CPU specified in the Pod configuration.
+slightly less than the limit of 1 CPU specified in the Pod configuration.
 -->
-此示例输出显示 Pod 使用的是 974 milliCPU，即仅略低于 Pod 配置中指定的 1 个 CPU 的限制。
+此示例输出显示 Pod 使用的是 974 milliCPU，即略低于 Pod 配置中指定的 1 个 CPU 的限制。
 
 ```
 NAME                        CPU(cores)   MEMORY(bytes)

content/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

@@ -8,10 +8,10 @@ weight: 110
 <!--
 This page shows how to configure liveness, readiness and startup probes for Containers.
 
-The [kubelet](/docs/admin/kubelet/) uses liveness probes to know when to
-restart a Container. For example, liveness probes could catch a deadlock,
+The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) uses liveness probes to know when to
+restart a container. For example, liveness probes could catch a deadlock,
 where an application is running, but unable to make progress. Restarting a
-Container in such a state can help to make the application more available
+container in such a state can help to make the application more available
 despite bugs.
 -->
 这篇文章介绍如何给容器配置存活、就绪和启动探测器。
@@ -22,12 +22,12 @@ despite bugs.
 这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。
 
 <!--
-The kubelet uses readiness probes to know when a Container is ready to start
-accepting traffic. A Pod is considered ready when all of its Containers are ready.
+The kubelet uses readiness probes to know when a container is ready to start
+accepting traffic. A Pod is considered ready when all of its containers are ready.
 One use of this signal is to control which Pods are used as backends for Services.
 When a Pod is not ready, it is removed from Service load balancers.
 
-The kubelet uses startup probes to know when a Container application has started.
+The kubelet uses startup probes to know when a container application has started.
 If such a probe is configured, it disables liveness and readiness checks until
 it succeeds, making sure those probes don't interfere with the application startup.
 This can be used to adopt liveness checks on slow starting containers, avoiding them
@@ -45,7 +45,7 @@ kubelet 使用启动探测器可以知道应用程序容器什么时候启动了
 
 ## {{% heading "prerequisites" %}}
 
-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}}
 
 <!-- steps -->
 
@@ -56,7 +56,7 @@ Many applications running for long periods of time eventually transition to
 broken states, and cannot recover except by being restarted. Kubernetes provides
 liveness probes to detect and remedy such situations.
 
-In this exercise, you create a Pod that runs a Container based on the
+In this exercise, you create a Pod that runs a container based on the
 `k8s.gcr.io/busybox` image. Here is the configuration file for the Pod:
 -->
 ## 定义存活命令 {#define-a-liveness-command}
@@ -70,16 +70,16 @@ Kubernetes 提供了存活探测器来发现并补救这种情况。
 {{< codenew file="pods/probe/exec-liveness.yaml" >}}
 
 <!--
-In the configuration file, you can see that the Pod has a single Container.
+In the configuration file, you can see that the Pod has a single `Container`.
 The `periodSeconds` field specifies that the kubelet should perform a liveness
 probe every 5 seconds. The `initialDelaySeconds` field tells the kubelet that it
-should wait 5 second before performing the first probe. To perform a probe, the
-kubelet executes the command `cat /tmp/healthy` in the Container. If the
-command succeeds, it returns 0, and the kubelet considers the Container to be alive and
-healthy. If the command returns a non-zero value, the kubelet kills the Container
+should wait 5 seconds before performing the first probe. To perform a probe, the
+kubelet executes the command `cat /tmp/healthy` in the target container. If the
+command succeeds, it returns 0, and the kubelet considers the container to be alive and
+healthy. If the command returns a non-zero value, the kubelet kills the container
 and restarts it.
 
-When the Container starts, it executes this command:
+When the container starts, it executes this command:
 -->
 在这个配置文件中，可以看到 Pod 中只有一个容器。
 `periodSeconds` 字段指定了 kubelet 应该每 5 秒执行一次存活探测。
@@ -95,7 +95,7 @@ kubelet 在容器内执行命令 `cat /tmp/healthy` 来进行探测。
 ```
 
 <!--
-For the first 30 seconds of the Container's life, there is a `/tmp/healthy` file.
+For the first 30 seconds of the container's life, there is a `/tmp/healthy` file.
 So during the first 30 seconds, the command `cat /tmp/healthy` returns a success
 code. After 30 seconds, `cat /tmp/healthy` returns a failure code.
 
@@ -195,14 +195,14 @@ image.
 {{< codenew file="pods/probe/http-liveness.yaml" >}}
 
 <!--
-In the configuration file, you can see that the Pod has a single Container.
+In the configuration file, you can see that the Pod has a single container.
 The `periodSeconds` field specifies that the kubelet should perform a liveness
 probe every 3 seconds. The `initialDelaySeconds` field tells the kubelet that it
 should wait 3 seconds before performing the first probe. To perform a probe, the
-kubelet sends an HTTP GET request to the server that is running in the Container
+kubelet sends an HTTP GET request to the server that is running in the container
 and listening on port 8080. If the handler for the server's `/healthz` path
-returns a success code, the kubelet considers the Container to be alive and
-healthy. If the handler returns a failure code, the kubelet kills the Container
+returns a success code, the kubelet considers the container to be alive and
+healthy. If the handler returns a failure code, the kubelet kills the container
 and restarts it.
 -->
 在这个配置文件中，可以看到 Pod 也只有一个容器。
@@ -217,14 +217,14 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any
 other code indicates failure.
 
 You can see the source code for the server in
-[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go).
+[server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go).
 
-For the first 10 seconds that the Container is alive, the `/healthz` handler
+For the first 10 seconds that the container is alive, the `/healthz` handler
 returns a status of 200. After that, the handler returns a status of 500.
 -->
 任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。
 
-可以在这里看服务的源码 [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go)。
+可以在这里看服务的源码 [server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go)。
 
 容器存活的最开始 10 秒中，`/healthz` 处理程序返回一个 200 的状态码。之后处理程序返回 500 的状态码。
 
@@ -242,9 +242,9 @@ http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
 ```
 
 <!--
-The kubelet starts performing health checks 3 seconds after the Container starts.
+The kubelet starts performing health checks 3 seconds after the container starts.
 So the first couple of health checks will succeed. But after 10 seconds, the health
-checks will fail, and the kubelet will kill and restart the Container.
+checks will fail, and the kubelet will kill and restart the container.
 
 To try the HTTP liveness check, create a Pod:
 -->
@@ -259,7 +259,7 @@ kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml
 
 <!--
 After 10 seconds, view Pod events to verify that liveness probes have failed and
-the Container has been restarted:
+the container has been restarted:
 -->
 10 秒之后，通过看 Pod 事件来检测存活探测器已经失败了并且容器被重新启动了。
 
@@ -269,7 +269,7 @@ kubectl describe pod liveness-http
 
 <!--
 In releases prior to v1.13 (including v1.13), if the environment variable
-`http_proxy` (or `HTTP_PROXY`) is set on the node where a pod is running,
+`http_proxy` (or `HTTP_PROXY`) is set on the node where a Pod is running,
 the HTTP liveness probe uses that proxy.
 In releases after v1.13, local HTTP proxy environment variable settings do not
 affect the HTTP liveness probe.
@@ -281,7 +281,7 @@ affect the HTTP liveness probe.
 <!--
 ## Define a TCP liveness probe
 
-A third type of liveness probe uses a TCP Socket. With this configuration, the
+A third type of liveness probe uses a TCP socket. With this configuration, the
 kubelet will attempt to open a socket to your container on the specified port.
 If it can establish a connection, the container is considered healthy, if it
 can't it is considered a failure.
@@ -298,13 +298,13 @@ 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
-connect to the `goproxy` container on port 8080. If the probe succeeds, the pod
+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.
 
 In addition to the readiness probe, this configuration includes a liveness probe.
 The kubelet will run the first liveness probe 15 seconds after the container
-starts. Just like the readiness probe, this will attempt to connect to the
+starts. Similar to the readiness probe, this will attempt to connect to the
 `goproxy` container on port 8080. If the liveness probe fails, the container
 will be restarted.
 
@@ -317,7 +317,7 @@ To try the TCP liveness check, create a Pod:
 
 除了就绪探测，这个配置包括了一个存活探测。
 kubelet 会在容器启动 15 秒后进行第一次存活探测。
-就像就绪探测一样，会尝试连接 `goproxy` 容器的 8080 端口。
+与就绪探测类似，会尝试连接 `goproxy` 容器的 8080 端口。
 如果存活探测失败，这个容器会被重新启动。
 
 ```shell
@@ -439,6 +439,14 @@ Readiness probes runs on the container during its whole lifecycle.
 就绪探测器在容器的整个生命周期中保持运行状态。
 {{< /note >}}
 
+<!--
+Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.
+-->
+{{< caution >}}
+活跃性探测器 *不等待* 就绪性探测器成功。
+如果要在执行活跃性探测器之前等待，应该使用 initialDelaySeconds 或 startupProbe。
+{{< /caution >}}
+
 <!--
 Readiness probes are configured similarly to liveness probes. The only difference
 is that you use the `readinessProbe` field instead of the `livenessProbe` field.
@@ -496,8 +504,8 @@ seconds. Minimum value is 1.
 * `timeoutSeconds`: Number of seconds after which the probe times out. Defaults
 to 1 second. Minimum value is 1.
 * `successThreshold`: Minimum consecutive successes for the probe to be
-considered successful after having failed. Defaults to 1. Must be 1 for
-liveness and startup Probes. Minimum value is 1.
+considered successful after having failed. Defaults to 1. Must be 1 for liveness
+and startup Probes. Minimum value is 1.
 * `failureThreshold`: When a probe fails, Kubernetes will
 try `failureThreshold` times before giving up. Giving up in case of liveness probe means restarting the container. In case of readiness probe the Pod will be marked Unready.
 Defaults to 3. Minimum value is 1.
@@ -511,6 +519,7 @@ Defaults to 3. Minimum value is 1.
   存活探测情况下的放弃就意味着重新启动容器。
   就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
 
+{{< note >}}
 <!--
 Before Kubernetes 1.20, the field `timeoutSeconds` was not respected for exec probes:
 probes continued running indefinitely, even past their configured deadline,
@@ -545,7 +554,7 @@ the process inside the container may keep running even after probe returned fail
 当此缺陷被修复之后，在使用 `dockershim` 容器运行时的 Kubernetes `1.20+`
 版本中，对于 exec 探针而言，容器中的进程可能会因为超时值的设置保持持续运行，
 即使探针返回了失败状态。
-
+{{< /note >}}
 {{< caution >}}
 <!--
 Incorrect implementation of readiness probes may result in an ever growing number
@@ -586,7 +595,7 @@ port to perform the check. The kubelet sends the probe to the pod's IP address,
 unless the address is overridden by the optional `host` field in `httpGet`. If
 `scheme` field is set to `HTTPS`, the kubelet sends an HTTPS request skipping the
 certificate verification. In most scenarios, you do not want to set the `host` field.
-Here's one scenario where you would set it. Suppose the Container listens on 127.0.0.1
+Here's one scenario where you would set it. Suppose the container listens on 127.0.0.1
 and the Pod's `hostNetwork` field is true. Then `host`, under `httpGet`, should be set
 to 127.0.0.1. If your pod relies on virtual hosts, which is probably the more common
 case, you should not use `host`, but rather set the `Host` header in `httpHeaders`.
@@ -658,6 +667,70 @@ to resolve it.
 对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接，
 这意味着你不能在 `host` 参数上配置服务名称，因为 kubelet 不能解析服务名称。
 
+<!--
+### Probe-level `terminationGracePeriodSeconds`
+-->
+### 探测器级别 `terminationGracePeriodSeconds`
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+<!--
+Prior to release 1.21, the pod-level `terminationGracePeriodSeconds` was used
+for terminating a container that failed its liveness or startup probe. This
+coupling was unintended and may have resulted in failed containers taking an
+unusually long time to restart when a pod-level `terminationGracePeriodSeconds`
+was set.
+-->
+在 1.21 版之前，pod 级别的 `terminationGracePeriodSeconds` 被用来终止
+未能成功处理活跃性探测或启动探测的容器。
+这种耦合是意料之外的，可能会导致在设置了 pod 级别的 `terminationGracePeriodSeconds` 后，
+需要很长的时间来重新启动失败的容器。
+
+<!--
+In 1.21, when the feature flag `ProbeTerminationGracePeriod` is enabled, users
+can specify a probe-level `terminationGracePeriodSeconds` as part of the probe
+specification. When the feature flag is enabled, and both a pod- and
+probe-level `terminationGracePeriodSeconds` are set, the kubelet will use the
+probe-level value.
+
+For example,
+-->
+在1.21中，启用特性标志 `ProbeTerminationGracePeriod` 后，
+用户可以指定一个探测器级别的 `terminationGracePeriodSeconds` 作为探测器规格的一部分。
+当该特性标志被启用时，若同时设置了 Pod 级别和探测器级别的 `terminationGracePeriodSeconds`，
+kubelet 将使用探测器级的值。
+
+例如，
+
+```yaml
+spec:
+  terminationGracePeriodSeconds: 3600  # pod-level
+  containers:
+  - name: test
+    image: ...
+
+    ports:
+    - name: liveness-port
+      containerPort: 8080
+      hostPort: 8080
+
+    livenessProbe:
+      httpGet:
+        path: /healthz
+        port: liveness-port
+      failureThreshold: 1
+      periodSeconds: 60
+      # Override pod-level terminationGracePeriodSeconds #
+      terminationGracePeriodSeconds: 60
+```
+
+<!--
+Probe-level `terminationGracePeriodSeconds` cannot be set for readiness probes.
+It will be rejected by the API server.
+-->
+探测器级别的 `terminationGracePeriodSeconds` 不能用于设置就绪态探针。
+它将被 API 服务器拒绝。
+
 ## {{% heading "whatsnext" %}}
 
 <!--
@@ -667,13 +740,13 @@ to resolve it.
 * 进一步了解[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
 
 <!--
-### Reference
+You can also read the API references for:
 
 * [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
 * [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
 * [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)
 -->
-### 参考 {#reference}
+你也可以阅读以下的 API 参考资料：
 
 * [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
 * [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)