Sync pod-lifecycle.md

content/zh-cn/docs/concepts/windows/intro.md

@@ -133,6 +133,7 @@ Kubernetes 关键组件在 Windows 上的工作方式与在 Linux 上相同。
   Linux containers in the same Pod. All containers in a Pod are scheduled onto a single
   Node where each Node represents a specific platform and architecture. The following
   Pod capabilities, properties and events are supported with Windows containers:
+
   * Single or multiple containers per Pod with process isolation and volume sharing
   * Pod `status` fields
   * Readiness, liveness, and startup probes
@@ -142,6 +143,7 @@ Kubernetes 关键组件在 Windows 上的工作方式与在 Linux 上相同。
   * Named pipe host mounts
   * Resource limits
   * OS field: 
+
     The `.spec.os.name` field should be set to `windows` to indicate that the current Pod uses Windows containers.
     The `IdentifyPodOS` feature gate needs to be enabled for this field to be recognized.
 
@@ -268,7 +270,7 @@ Some kubelet command line options behave differently on Windows, as described be
 <!--
 * The `--windows-priorityclass` lets you set the scheduling priority of the kubelet process
   (see [CPU resource management](/docs/concepts/configuration/windows-resource-management/#resource-management-cpu))
-* The `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update
+* The `--kube-reserved`, `--system-reserved` , and `--eviction-hard` flags update
   [NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
 * Eviction by using `--enforce-node-allocable` is not implemented
 * Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented
@@ -282,7 +284,7 @@ Some kubelet command line options behave differently on Windows, as described be
 -->
 * `--windows-priorityclass` 允许你设置 kubelet 进程的调度优先级
   （参考 [CPU 资源管理](/zh-cn/docs/concepts/configuration/windows-resource-management/#resource-management-cpu)）。
-* `--kubelet-reserve`、`--system-reserve` 和 `--eviction-hard` 标志更新
+* `--kube-reserved`、`--system-reserved` 和 `--eviction-hard` 标志更新
   [NodeAllocatable](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)。
 * 未实现使用 `--enforce-node-allocable` 驱逐。
 * 未实现使用 `--eviction-hard` 和 `--eviction-soft` 驱逐。
@@ -341,6 +343,7 @@ At a high level, these OS concepts are different:
   * Console apps handle Ctrl-C or Ctrl-break using a Control Handler.
   * Services register a Service Control Handler function that can accept
     `SERVICE_CONTROL_STOP` control codes.
+
 Container exit codes follow the same convention where 0 is success, and nonzero is failure.
 The specific error codes may differ across Windows and Linux. However, exit codes
 passed from the Kubernetes components (kubelet, kube-proxy) are unchanged.
@@ -598,7 +601,8 @@ kernel patch.
 <!--
 #### Mirantis Container Runtime {#mcr}
 
-[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) is available as a container runtime for all Windows Server 2019 and later versions.
+[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR)
+is available as a container runtime for all Windows Server 2019 and later versions.
 
 See [Install MCR on Windows Servers](https://docs.mirantis.com/mcr/20.10/install/mcr-windows.html) for more information.
 -->
@@ -706,7 +710,8 @@ Kubernetes [集群 API](https://cluster-api.sigs.k8s.io/) 项目也提供了自
 <!--
 ### Windows distribution channels
 
-For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
+For a detailed explanation of Windows distribution channels see the
+[Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
 
 Information on the different Windows Server servicing channels
 including their support models can be found at

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

@@ -159,6 +159,19 @@ Value | Description
 `Failed`（失败） | Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。
 `Unknown`（未知） | 因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。
 
+<!--
+When a Pod is being deleted, it is shown as `Terminating` by some kubectl commands.
+This `Terminating` status is not one of the Pod phases.
+A Pod is granted a term to terminate gracefully, which defaults to 30 seconds.
+You can use the flag `--force` to [terminate a Pod by force](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced).
+-->
+{{< note >}}
+当一个 Pod 被删除时，执行一些 kubectl 命令会展示这个 Pod 的状态为 `Terminating`（终止）。
+这个 `Terminating` 状态并不是 Pod 阶段之一。
+Pod 被赋予一个可以体面终止的期限，默认为 30 秒。
+你可以使用 `--force` 参数来[强制终止 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-forced)。
+{{< /note >}}
+
 <!--
 If a node dies or is disconnected from the rest of the cluster, Kubernetes
 applies a policy for setting the `phase` of all Pods on the lost node to Failed.
@@ -312,6 +325,7 @@ Pod 有一个 PodStatus 对象，其中包含一个
 
 <!--
 Field name           | Description
+:--------------------|:-----------
 `type`               | Name of this Pod condition.
 `status`             | Indicates whether that condition is applicable, with possible values "`True`", "`False`", or "`Unknown`".
 `lastProbeTime`      | Timestamp of when the Pod condition was last probed.
@@ -339,7 +353,7 @@ specify a list of additional conditions that the kubelet evaluates for Pod readi
 
 {{< feature-state for_k8s_version="v1.14" state="stable" >}}
 
-你的应用可以向 PodStatus 中注入额外的反馈或者信号：_Pod Readiness（Pod 就绪态）_。
+你的应用可以向 PodStatus 中注入额外的反馈或者信号：**Pod Readiness（Pod 就绪态）**。
 要使用这一特性，可以设置 Pod 规约中的 `readinessGates` 列表，为 kubelet
 提供一组额外的状况供其评估 Pod 就绪态时使用。
 
@@ -662,7 +676,7 @@ to stop.
 -->
 #### 何时该使用启动探针？   {#when-should-you-use-a-startup-probe}
 
-{{< feature-state for_k8s_version="v1.18" state="beta" >}}
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
 <!--
 Startup probes are useful for Pods that have containers that take a long time to
@@ -706,7 +720,7 @@ The design aim is for you to be able to request deletion and know when processes
 terminate, but also be able to ensure that deletes eventually complete.
 When you request deletion of a Pod, the cluster records and tracks the intended grace period
 before the Pod is allowed to be forcefully killed. With that forceful shutdown tracking in
-place, the {< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful
+place, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} attempts graceful
 shutdown.
 -->
 设计的目标是令你能够请求删除进程，并且知道进程何时被终止，同时也能够确保删除
@@ -719,7 +733,7 @@ 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 remainig
+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
@@ -828,7 +842,7 @@ An example flow:
 Forced deletions can be potentially disruptive for some workloads and their Pods.
 
 By default, all deletes are graceful within 30 seconds. The `kubectl delete` command supports
-the `-grace-period=<seconds>` option which allows you to override the default and specify your
+the `--grace-period=<seconds>` option which allows you to override the default and specify your
 own value.
 -->
 ### 强制终止 Pod     {#pod-termination-forced}