Merge pull request #42980 from my-git9/workloads12

[zh-cn] sync concepts/workloads/*

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

@@ -77,7 +77,7 @@ This example CronJob manifest prints the current time and a hello message every
 
 下面的 CronJob 示例清单会在每分钟打印出当前时间和问候消息：
 
-{{% code file="application/job/cronjob.yaml" %}}
+{{% code_sample file="application/job/cronjob.yaml" %}}
 
 <!--
 ([Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)

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

@@ -73,7 +73,7 @@ describes a DaemonSet that runs the fluentd-elasticsearch Docker image:
 你可以在 YAML 文件中描述 DaemonSet。
 例如，下面的 daemonset.yaml 文件描述了一个运行 fluentd-elasticsearch Docker 镜像的 DaemonSet：
 
-{{% code file="controllers/daemonset.yaml" %}}
+{{% code_sample file="controllers/daemonset.yaml" %}}
 
 <!--
 Create a DaemonSet based on the YAML file:
@@ -478,7 +478,9 @@ number of replicas and rolling out updates are more important than controlling e
 the Pod runs on.  Use a DaemonSet when it is important that a copy of a Pod always run on
 all or certain hosts, if the DaemonSet provides node-level functionality that allows other Pods to run correctly on that particular node.
 
-For example, [network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) often include a component that runs as a DaemonSet. The DaemonSet component makes sure that the node where it's running has working cluster networking.
+For example, [network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
+often include a component that runs as a DaemonSet. The DaemonSet component makes sure
+that the node where it's running has working cluster networking.
 -->
 ### Deployment
 

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

@@ -38,7 +38,7 @@ A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods"
 <!--
 You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
 -->
-你负责描述 Deployment 中的 **目标状态**，而 Deployment {{< glossary_tooltip term_id="controller" >}}
+你负责描述 Deployment 中的**目标状态**，而 Deployment {{< glossary_tooltip term_id="controller" >}}
 以受控速率更改实际状态，
 使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment，
 并通过新的 Deployment 收养其资源。
@@ -47,7 +47,7 @@ You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_
 <!--
 Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.
 -->
-不要管理 Deployment 所拥有的 ReplicaSet 。
+不要管理 Deployment 所拥有的 ReplicaSet。
 如果存在下面未覆盖的使用场景，请考虑在 Kubernetes 仓库中提出 Issue。
 {{< /note >}}
 
@@ -91,7 +91,7 @@ The following is an example of a Deployment. It creates a ReplicaSet to bring up
 -->
 下面是一个 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个 `nginx` Pod：
 
-{{% code file="controllers/nginx-deployment.yaml" %}}
+{{% code_sample file="controllers/nginx-deployment.yaml" %}}
 
 <!--
 In this example:
@@ -2199,7 +2199,10 @@ Deployment 的修订历史记录存储在它所控制的 ReplicaSets 中。
 
 <!--
 `.spec.revisionHistoryLimit` is an optional field that specifies the number of old ReplicaSets to retain
-to allow rollback. These old ReplicaSets consume resources in `etcd` and crowd the output of `kubectl get rs`. The configuration of each Deployment revision is stored in its ReplicaSets; therefore, once an old ReplicaSet is deleted, you lose the ability to rollback to that revision of Deployment. By default, 10 old ReplicaSets will be kept, however its ideal value depends on the frequency and stability of new Deployments.
+to allow rollback. These old ReplicaSets consume resources in `etcd` and crowd the output of `kubectl get rs`.
+The configuration of each Deployment revision is stored in its ReplicaSets; therefore, once an old ReplicaSet is deleted,
+you lose the ability to rollback to that revision of Deployment. By default, 10 old ReplicaSets will be kept,
+however its ideal value depends on the frequency and stability of new Deployments.
 -->
 `.spec.revisionHistoryLimit` 是一个可选字段，用来设定出于回滚目的所要保留的旧 ReplicaSet 数量。
 这些旧 ReplicaSet 会消耗 etcd 中的资源，并占用 `kubectl get rs` 的输出。

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

@@ -73,7 +73,7 @@ It takes around 10s to complete.
 下面是一个 Job 配置示例。它负责计算 π 到小数点后 2000 位，并将结果打印出来。
 此计算大约需要 10 秒钟完成。
 
-{{% code file="controllers/job.yaml" %}}
+{{% code_sample file="controllers/job.yaml" %}}
 
 <!--
 You can run the example with this command:
@@ -712,7 +712,7 @@ Here is an example manifest for a Job that defines a `backoffLimitPerIndex`:
 -->
 以下是定义 `backoffLimitPerIndex` 的 Job 示例清单：
 
-{{< codenew file="/controllers/job-backoff-limit-per-index-example.yaml" >}}
+{{% code_sample file="/controllers/job-backoff-limit-per-index-example.yaml" %}}
 
 <!--
 In the example above, the Job controller allows for one restart for each
@@ -829,7 +829,7 @@ Here is a manifest for a Job that defines a `podFailurePolicy`:
 -->
 下面是一个定义了 `podFailurePolicy` 的 Job 的清单：
 
-{{% code file="/controllers/job-pod-failure-policy-example.yaml" %}}
+{{% code_sample file="/controllers/job-pod-failure-policy-example.yaml" %}}
 
 <!--
 In the example above, the first rule of the Pod failure policy specifies that

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

@@ -113,7 +113,7 @@ Deployment，并在 spec 部分定义你的应用。
 -->
 ## 示例    {#example}
 
-{{% code file="controllers/frontend.yaml" %}}
+{{% code_sample file="controllers/frontend.yaml" %}}
 
 <!--
 Saving this manifest into `frontend.yaml` and submitting it to a Kubernetes cluster will
@@ -263,7 +263,7 @@ Pod，它还可以像前面小节中所描述的那样获得其他 Pod。
 
 以前面的 frontend ReplicaSet 为例，并在以下清单中指定这些 Pod：
 
-{{% code file="pods/pod-rs.yaml" %}}
+{{% code_sample file="pods/pod-rs.yaml" %}}
 
 <!--
 As those Pods do not have a Controller (or any object) as their owner reference and match the selector of the frontend
@@ -668,7 +668,7 @@ ReplicaSet 也可以作为[水平的 Pod 扩缩器 (HPA)](/zh-cn/docs/tasks/run-
 的目标。也就是说，ReplicaSet 可以被 HPA 自动扩缩。
 以下是 HPA 以我们在前一个示例中创建的副本集为目标的示例。
 
-{{% code file="controllers/hpa-rs.yaml" %}}
+{{% code_sample file="controllers/hpa-rs.yaml" %}}
 
 <!--
 Saving this manifest into `hpa-rs.yaml` and submitting it to a Kubernetes cluster should

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

@@ -81,7 +81,7 @@ This example ReplicationController config runs three copies of the nginx web ser
 
 这个示例 ReplicationController 配置运行 nginx Web 服务器的三个副本。
 
-{{% code file="controllers/replication.yaml" %}}
+{{% code_sample file="controllers/replication.yaml" %}}
 
 <!--
 Run the example job by downloading the example file and then running this command:
@@ -384,15 +384,21 @@ Pods may be removed from a ReplicationController's target set by changing their
 <!--
 ### Rescheduling
 
-As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (for example, due to an action by another control agent).
+As mentioned above, whether you have 1 pod you want to keep running, or 1000, a
+ReplicationController will ensure that the specified number of pods exists, even
+in the event of node failure or pod termination (for example, due to an action
+by another control agent).
 -->
 ### 重新调度   {#rescheduling}
 
-如上所述，无论你想要继续运行 1 个 Pod 还是 1000 个 Pod，一个 ReplicationController 都将确保存在指定数量的 Pod，即使在节点故障或 Pod 终止(例如，由于另一个控制代理的操作)的情况下也是如此。
+如上所述，无论你想要继续运行 1 个 Pod 还是 1000 个 Pod，一个
+ReplicationController 都将确保存在指定数量的 Pod，即使在节点故障或
+Pod 终止（例如，由于另一个控制代理的操作）的情况下也是如此。
 <!--
 ### Scaling
 
-The ReplicationController enables scaling the number of replicas up or down, either manually or by an auto-scaling control agent, by updating the `replicas` field.
+The ReplicationController enables scaling the number of replicas up or down,
+either manually or by an auto-scaling control agent, by updating the `replicas` field.
 -->
 ### 扩缩容   {#scaling}
 
@@ -419,9 +425,11 @@ Ideally, the rolling update controller would take application readiness into acc
 
 The two ReplicationControllers would need to create pods with at least one differentiating label, such as the image tag of the primary container of the pod, since it is typically image updates that motivate rolling updates.
 -->
-理想情况下，滚动更新控制器将考虑应用程序的就绪情况，并确保在任何给定时间都有足够数量的 Pod 有效地提供服务。
+理想情况下，滚动更新控制器将考虑应用程序的就绪情况，并确保在任何给定时间都有足够数量的
+Pod 有效地提供服务。
 
-这两个 ReplicationController 将需要创建至少具有一个不同标签的 Pod，比如 Pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。
+这两个 ReplicationController 将需要创建至少具有一个不同标签的 Pod，
+比如 Pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。
 
 <!--
 ### Multiple release tracks
@@ -555,7 +563,8 @@ because they are declarative, server-side, and have additional features.
 -->
 ### Deployment （推荐）
 
-[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。
+[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/)
+是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。
 如果你想要这种滚动更新功能，那么推荐使用 Deployment，因为它们是声明式的、服务端的，并且具有其它特性。
 
 <!--

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

@@ -3,9 +3,6 @@ title: Pod
 content_type: concept
 weight: 10
 no_list: true
-card:
-  name: concepts
-  weight: 60
 ---
 <!--
 reviewers:
@@ -14,9 +11,6 @@ title: Pods
 content_type: concept
 weight: 10
 no_list: true
-card:
-  name: concepts
-  weight: 60
 -->
 
 <!-- overview -->
@@ -25,11 +19,13 @@ card:
 _Pods_ are the smallest deployable units of computing that you can create and manage in Kubernetes.
 
 A _Pod_ (as in a pod of whales or pea pod) is a group of one or more
-{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage and network resources, and a specification for how to run the containers. A Pod's contents are always co-located and
+{{< glossary_tooltip text="containers" term_id="container" >}}, with shared storage and network resources,
+and a specification for how to run the containers. A Pod's contents are always co-located and
 co-scheduled, and run in a shared context. A Pod models an
 application-specific "logical host": it contains one or more application
 containers which are relatively tightly coupled. 
-In non-cloud contexts, applications executed on the same physical or virtual machine are analogous to cloud applications executed on the same logical host.
+In non-cloud contexts, applications executed on the same physical or virtual machine are
+analogous to cloud applications executed on the same logical host.
 -->
 **Pod** 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。
 
@@ -70,7 +66,8 @@ into each node in the cluster so that Pods can run there.
 
 <!--
 The shared context of a Pod is a set of Linux namespaces, cgroups, and
-potentially other facets of isolation - the same things that isolate a {{< glossary_tooltip text="container" term_id="container" >}}. Within a Pod's context, the individual applications may have
+potentially other facets of isolation - the same things that isolate a {{< glossary_tooltip text="container" term_id="container" >}}.
+Within a Pod's context, the individual applications may have
 further sub-isolations applied.
 
 A Pod is similar to a set of containers with shared namespaces and shared filesystem volumes.
@@ -90,7 +87,7 @@ The following is an example of a Pod which consists of a container running the i
 
 下面是一个 Pod 示例，它由一个运行镜像 `nginx:1.14.2` 的容器组成。
 
-{{% code file="pods/simple-pod.yaml" %}}
+{{% code_sample file="pods/simple-pod.yaml" %}}
 
 <!--
 To create the Pod shown above, run the following command:
@@ -114,7 +111,8 @@ Pod 通常不是直接创建的，而是使用工作负载资源创建的。
 ### 用于管理 Pod 的工作负载资源   {#workload-resources-for-managing-pods}
 
 <!--
-Usually you don't need to create Pods directly, even singleton Pods. Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
+Usually you don't need to create Pods directly, even singleton Pods. Instead,
+create them using workload resources such as {{< glossary_tooltip text="Deployment"
 term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
 If your Pods need to track state, consider the
 {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} resource.
@@ -207,15 +205,32 @@ that updates those files from a remote source, as in the following diagram:
 {{< figure src="/zh-cn/docs/images/pod.svg" alt="Pod 创建示意图" class="diagram-medium" >}}
 
 <!--
-Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
-
-Pods natively provide two kinds of shared resources for their constituent containers:
-[networking](#pod-networking) and [storage](#pod-storage).
+Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}}
+as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}.
+Init containers run and complete before the app containers are started.
 -->
 有些 Pod 具有 {{< glossary_tooltip text="Init 容器" term_id="init-container" >}}和
 {{< glossary_tooltip text="应用容器" term_id="app-container" >}}。
 Init 容器会在启动应用容器之前运行并完成。
 
+{{< feature-state for_k8s_version="v1.28" state="alpha" >}}
+
+<!--
+Enabling the `SidecarContainers` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+allows you to specify `restartPolicy: Always` for init containers.
+Setting the `Always` restart policy ensures that the init containers where you set it are
+kept running during the entire lifetime of the Pod.
+See [Sidecar containers and restartPolicy](/docs/concepts/workloads/pods/init-containers/#sidecar-containers-and-restartpolicy)
+for more details.
+-->
+启用 `SidecarContainers` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)允许你为
+Init 容器指定 `restartPolicy: Always`。设置重启策略为 `Always` 会确保 Init 容器在 Pod 的整个生命周期内保持运行。
+更多细节参阅[边车容器和重启策略](/zh-cn/docs/concepts/workloads/pods/init-containers/#sidecar-containers-and-restartpolicy)
+
+<!--
+Pods natively provide two kinds of shared resources for their constituent containers:
+[networking](#pod-networking) and [storage](#pod-storage).
+-->
 Pod 天生地为其成员容器提供了两种共享资源：[网络](#pod-networking)和[存储](#pod-storage)。
 
 <!--
@@ -286,7 +301,7 @@ field to avoid enforcing policies that aren't relevant to that operating system.
 
 在 Kubernetes v{{< skew currentVersion >}} 中，为此字段设置的值对 Pod
 的{{<glossary_tooltip text="调度" term_id="kube-scheduler" >}}没有影响。
-设置 `. spec.os.name` 有助于确定性地标识 Pod 的操作系统并用于验证。
+设置 `.spec.os.name` 有助于确定性地标识 Pod 的操作系统并用于验证。
 如果你指定的 Pod 操作系统与运行 kubelet 所在节点的操作系统不同，
 那么 kubelet 将会拒绝运行该 Pod。
 [Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)也使用这个字段来避免强制执行与该操作系统无关的策略。
@@ -329,7 +344,7 @@ PodTemplates are specifications for creating Pods, and are included in workload
 ### Pod 模板    {#pod-templates}
 
 {{< glossary_tooltip text="工作负载" term_id="workload" >}}资源的控制器通常使用
-**Pod 模板（Pod Template）** 来替你创建 Pod 并管理它们。
+**Pod 模板（Pod Template）**来替你创建 Pod 并管理它们。
 
 Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
 [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)、
@@ -539,7 +554,8 @@ Pod 中的容器所看到的系统主机名与为 Pod 配置的 `name` 属性值
 
 {{< note >}}
 <!--
-Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must support the concept of a privileged container for this setting to be relevant.
+Your {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} must
+support the concept of a privileged container for this setting to be relevant.
 -->
 你的{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}必须支持特权容器的概念才能使用这一配置。
 {{< /note >}}
@@ -596,7 +612,7 @@ Pods, the kubelet directly supervises each static Pod (and restarts it if it fai
 -->
 ## 静态 Pod    {#static-pods}
 
-**静态 Pod（Static Pod）** 直接由特定节点上的 `kubelet` 守护进程管理，
+**静态 Pod（Static Pod）**直接由特定节点上的 `kubelet` 守护进程管理，
 不需要 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}看到它们。
 尽管大多数 Pod 都是通过控制面（例如，{{< glossary_tooltip text="Deployment" term_id="deployment" >}}）
 来管理的，对于静态 Pod 而言，`kubelet` 直接监控每个 Pod，并在其失效时重启之。

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

@@ -551,7 +551,7 @@ Here's an example of a Deployment with two containers, one of which is a sidecar
 
 以下是一个具有两个容器的 Deployment 示例，其中一个是边车：
 
-{{% codenew language="yaml" file="application/deployment-sidecar.yaml" %}}
+{{% code_sample language="yaml" file="application/deployment-sidecar.yaml" %}}
 
 <!--
 This feature is also useful for running Jobs with sidecars, as the sidecar
@@ -564,7 +564,7 @@ Here's an example of a Job with two containers, one of which is a sidecar:
 
 以下是一个具有两个容器的 Job 示例，其中一个是边车：
 
-{{% codenew language="yaml" file="application/job/job-sidecar.yaml" %}}
+{{% code_sample language="yaml" file="application/job/job-sidecar.yaml" %}}
 
 <!--
 #### Resource sharing within containers