diff --git a/content/zh-cn/blog/_posts/2023-04-18-efficient-selinux-relabeling-beta.md b/content/zh-cn/blog/_posts/2023-04-18-efficient-selinux-relabeling-beta.md
new file mode 100644
index 0000000000..2954753188
--- /dev/null
+++ b/content/zh-cn/blog/_posts/2023-04-18-efficient-selinux-relabeling-beta.md
@@ -0,0 +1,180 @@
+---
+layout: blog
+title: "Kubernetes 1.27：高效的 SELinux 卷重新标记（Beta 版）"
+date: 2023-04-18T10:00:00-08:00
+slug: kubernetes-1-27-efficient-selinux-relabeling-beta
+---
+
+<!--
+layout: blog
+title: "Kubernetes 1.27: Efficient SELinux volume relabeling (Beta)"
+date: 2023-04-18T10:00:00-08:00
+slug: kubernetes-1-27-efficient-selinux-relabeling-beta
+-->
+
+**作者**：Jan Šafránek (Red Hat)
+<!--
+**Author:** Jan Šafránek (Red Hat)
+-->
+
+**译者**：Wilson Wu (DaoCloud)
+
+<!--
+## The problem
+-->
+## 问题 {#the-problem}
+
+<!--
+On Linux with Security-Enhanced Linux (SELinux) enabled, it's traditionally the container runtime that applies SELinux labels to a Pod and all its volumes. Kubernetes only passes the SELinux label from a Pod's `securityContext` fields to the container runtime.
+-->
+在启用了 Security-Enhancled Linux（SELinux）系统上，传统做法是让容器运行时负责为
+Pod 及所有卷应用 SELinux 标签。
+Kubernetes 仅将 SELinux 标签从 Pod 的 `securityContext` 字段传递给容器运行时。
+
+<!--
+The container runtime then recursively changes SELinux label on all files that are visible to the Pod's containers. This can be time-consuming if there are many files on the volume, especially when the volume is on a remote filesystem.
+-->
+然后，容器运行时以递归的方式更改 Pod 容器可见的所有文件上的 SELinux 标签。
+如果卷上有许多文件，这一过程可能会非常耗时，尤其是当卷位于远程文件系统上时。
+
+{{% alert title="Note" color="info" %}}
+<!--
+If a container uses `subPath` of a volume, only that `subPath` of the whole volume is relabeled. This allows two pods that have two different SELinux labels to use the same volume, as long as they use different subpaths of it.
+-->
+如果容器使用卷的 `subPath`，则系统仅重新标记整个卷的 `subPath`。
+这样，使用不同 SELinux 标签的两个 Pod 可以使用同一卷，只要它们使用该卷的不同子路径即可。
+{{% /alert %}}
+
+<!--
+If a Pod does not have any SELinux label assigned in Kubernetes API, the container runtime assigns a unique random one, so a process that potentially escapes the container boundary cannot access data of any other container on the host. The container runtime still recursively relabels all pod volumes with this random SELinux label.
+-->
+如果 Pod 没有从 Kubernetes API 中获得任何 SELinux 标签，则容器运行时会分配一个唯一的随机标签，
+因此可能逃离容器边界的进程将无法访问主机上任何其他容器的数据。
+容器运行时仍然使用此随机 SELinux 标签递归地重新标记所有 Pod 卷。
+
+<!--
+## Improvement using mount options
+-->
+## 使用挂载选项进行改进 {#improvement-using-mount-options}
+
+<!--
+If a Pod and its volume meet **all** of the following conditions, Kubernetes will _mount_ the volume directly with the right SELinux label. Such mount will happen in a constant time and the container runtime will not need to recursively relabel any files on it.
+-->
+如果 Pod 及其卷满足以下所有条件，Kubernetes 将直接使用正确的 SELinux 标签挂载该卷。
+这种挂载将在确定时间内完成，容器运行时不需要递归地重新标记其上的任何文件。
+
+<!--
+1. The operating system must support SELinux.
+
+   Without SELinux support detected, kubelet and the container runtime do not do anything with regard to SELinux.
+-->
+1. 操作系统必须支持 SELinux。
+
+   如果没有检测到 SELinux 支持，kubelet 和容器运行时不会对 SELinux 执行任何操作。
+
+<!--
+1. The [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) `ReadWriteOncePod` and `SELinuxMountReadWriteOncePod` must be enabled. These feature gates are Beta in Kubernetes 1.27 and Alpha in 1.25.
+
+   With any of these feature gates disabled, SELinux labels will be always applied by the container runtime by a recursive walk through the volume (or its subPaths).
+-->
+2. 必须启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
+   `ReadWriteOncePod` 和 `SELinuxMountReadWriteOncePod`。这些特性门控在 Kubernetes 1.27 中是 Beta 版，在 1.25 中是 Alpha 版。
+
+   禁用这些功能中任何一个后，SELinux 标签将始终由容器运行时通过递归遍历卷（或其 subPath）来应用。
+
+<!--
+1. The Pod must have at least `seLinuxOptions.level` assigned in its [Pod Security Context](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) or all Pod containers must have it set in their [Security Contexts](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1). Kubernetes will read the default `user`, `role` and `type` from the operating system defaults (typically `system_u`, `system_r` and `container_t`).
+
+   Without Kubernetes knowing at least the SELinux `level`, the container runtime will assign a random one _after_ the volumes are mounted. The container runtime will still relabel the volumes recursively in that case.
+-->
+3. Pod 必须在其 [Pod 安全上下文](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context)中至少分配
+   `seLinuxOptions.level`，或者所有 Pod 容器必须在[安全上下文](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1)中对其进行设置。
+   否则 Kubernetes 将从操作系统默认值（通常是 `system_u`、`system_r` 和 `container_t`）中读取默认的 `user`、`role` 和 `type`。
+
+   如果 Kubernetes 不了解任何 SELinux `level`，容器运行时将在卷挂载**后**为其分配一个随机级别。
+   在这种情况下，容器运行时仍会递归地对卷进行重新标记。
+
+<!--
+1. The volume must be a Persistent Volume with [Access Mode](/docs/concepts/storage/persistent-volumes/#access-modes) `ReadWriteOncePod`.
+
+   This is a limitation of the initial implementation. As described above, two Pods can have a different SELinux label and still use the same volume, as long as they use a different `subPath` of it. This use case is not possible when the volumes are _mounted_ with the SELinux label, because the whole volume is mounted and most filesystems don't support mounting a single volume multiple times with multiple SELinux labels.
+
+   If running two Pods with two different SELinux contexts and using different `subPaths` of the same volume is necessary in your deployments, please comment in the [KEP](https://github.com/kubernetes/enhancements/issues/1710) issue (or upvote any existing comment - it's best not to duplicate). Such pods may not run when the feature is extended to cover all volume access modes.
+-->
+4. 该卷必须是[访问模式](/zh-cn/docs/concepts/storage/persistent-volumes/#access-modes) `ReadWriteOncePod` 的持久卷。
+
+   这是最初实施的限制。如上所述，两个 Pod 可以具有不同的 SELinux 标签，但仍然使用相同的卷，
+   只要它们使用不同的 `subPath` 即可。当使用 SELinux 标签的**已挂载**卷时，此用例是不可能实现的，
+   因为整个卷已挂载，并且大多数文件系统不支持使用多个 SELinux 标签多次挂载单个卷。
+
+   如果在部署中需要使用两个不同的 SELinux 上下文运行两个 Pod 并使用同一卷的不同 `subPath`，
+   请在 [KEP](https://github.com/kubernetes/enhancements/issues/1710) 问题中发表评论（或对任何现有评论进行投票 - 最好不要重复）。
+   当功能扩展到覆盖所有卷访问模式时，此类 Pod 可能无法运行。
+
+<!--
+1. The volume plugin or the CSI driver responsible for the volume supports mounting with SELinux mount options.
+
+   These in-tree volume plugins support mounting with SELinux mount options: `fc`, `iscsi`, and `rbd`.
+
+   CSI drivers that support mounting with SELinux mount options must announce that in their [CSIDriver](/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1/) instance by setting `seLinuxMount` field.
+
+   Volumes managed by other volume plugins or CSI drivers that don't set `seLinuxMount: true` will be recursively relabelled by the container runtime.
+-->
+5. 卷插件或负责卷的 CSI 驱动程序支持使用 SELinux 挂载选项进行挂载。
+
+   这些树内卷插件支持使用 SELinux 挂载选项进行挂载：`fc`、`iscsi` 和 `rbd`。
+
+   支持使用 SELinux 挂载选项挂载的 CSI 驱动程序必须通过设置 `seLinuxMount`
+   字段在其 [CSIDriver](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1/) 实例中声明这一点。
+
+   由其他未设置 `seLinuxMount: true` 的卷插件或 CSI 驱动程序管理的卷将由容器运行时递归地重新标记。
+
+<!--
+### Mounting with SELinux context
+-->
+### 使用 SELinux 上下文挂载 {#mounting-with-selinux-context}
+
+<!--
+When all aforementioned conditions are met, kubelet will pass `-o context=<SELinux label>` mount option to the volume plugin or CSI driver. CSI driver vendors must ensure that this mount option is supported by their CSI driver and, if necessary, the CSI driver appends other mount options that are needed for `-o context` to work.
+-->
+当满足所有上述条件时，kubelet 会将 `-o context=<SELinux label>` 挂载选项传递给卷插件或 CSI 驱动程序。
+CSI 驱动程序供应商必须确保其 CSI 驱动程序支持此安装选项，并且如有必要，CSI 驱动程序会附加 `-o context` 工作所需的其他安装选项。
+
+<!--
+For example, NFS may need `-o context=<SELinux label>,nosharecache`, so each volume mounted from the same NFS server can have a different SELinux label value. Similarly, CIFS may need `-o context=<SELinux label>,nosharesock`.
+-->
+例如，NFS 可能需要 `-o context=<SELinux label>,nosharecache`，因此从同一 NFS 服务器挂载的每个卷可以具有不同的 SELinux 标签值。
+类似地，CIFS 可能需要 `-o context=<SELinux label>,nosharesock`。
+
+<!--
+It's up to the CSI driver vendor to test their CSI driver in a SELinux enabled environment before setting `seLinuxMount: true` in the CSIDriver instance.
+-->
+在 CSIDriver 实例中设置 `seLinuxMount: true` 之前，CSI 驱动程序供应商需要在启用 SELinux 的环境中测试其 CSI 驱动程序。
+
+<!--
+## How can I learn more?
+-->
+## 如何了解更多？ {#how-can-i-learn-more}
+
+<!--
+SELinux in containers: see excellent [visual SELinux guide](https://opensource.com/business/13/11/selinux-policy-guide) by Daniel J Walsh. Note that the guide is older than Kubernetes, it describes *Multi-Category Security* (MCS) mode using virtual machines as an example, however, a similar concept is used for containers.
+-->
+容器中的 SELinux：请参阅 Daniel J Walsh 撰写的优秀 [可视化 SELinux 指南（英文）](https://opensource.com/business/13/11/selinux-policy-guide)。
+请注意，该指南早于 Kubernetes，它以虚拟机为例描述了**多类别安全**（MCS）模式，但是，类似的概念也适用于容器。
+
+<!--
+See a series of blog posts for details how exactly SELinux is applied to containers by container runtimes:
+-->
+请参阅以下系列博客文章，详细了解容器运行时如何将 SELinux 应用于容器：
+
+<!--
+* [How SELinux separates containers using Multi-Level Security](https://www.redhat.com/en/blog/how-selinux-separates-containers-using-multi-level-security)
+* [Why you should be using Multi-Category Security for your Linux containers](https://www.redhat.com/en/blog/why-you-should-be-using-multi-category-security-your-linux-containers)
+-->
+* [SELinux 如何使用多级安全性分离容器](https://www.redhat.com/en/blog/how-selinux-separates-containers-using-multi-level-security)
+* [为什么应该为 Linux 容器使用多类别安全性](https://www.redhat.com/en/blog/why-you-should-be-using-multi-category-security-your-linux-containers)
+
+<!--
+Read the KEP: [Speed up SELinux volume relabeling using mounts](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1710-selinux-relabeling)
+-->
+阅读 KEP：[使用挂载加速 SELinux 卷重新标记](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1710-selinux-relabeling)
diff --git a/content/zh-cn/blog/_posts/2023-08-25-sidecar-kep.md b/content/zh-cn/blog/_posts/2023-08-25-sidecar-kep.md
index ab359fd4de..6fde55894d 100644
--- a/content/zh-cn/blog/_posts/2023-08-25-sidecar-kep.md
+++ b/content/zh-cn/blog/_posts/2023-08-25-sidecar-kep.md
@@ -1,48 +1,47 @@
 ---
 layout: blog
-title: "Kubernetes 1.28：介绍原生 Sidecar 容器"
+title: "Kubernetes v1.28：介绍原生边车容器"
 date: 2023-08-25
 slug: native-sidecar-containers
 ---
 
-<!-- 
+<!--
 layout: blog
 title: "Kubernetes v1.28: Introducing native sidecar containers"
 date: 2023-08-25
-slug: native-sidecar-containers 
+slug: native-sidecar-containers
 -->
 
-<!-- 
-***Authors:*** Todd Neal (AWS), Matthias Bertschy (ARMO), Sergey Kanzhelev (Google), Gunju Kim (NAVER), Shannon Kularathna (Google) 
+**作者**：Todd Neal (AWS), Matthias Bertschy (ARMO), Sergey Kanzhelev (Google), Gunju Kim (NAVER), Shannon Kularathna (Google)
+<!--
+***Authors:*** Todd Neal (AWS), Matthias Bertschy (ARMO), Sergey Kanzhelev (Google), Gunju Kim (NAVER), Shannon Kularathna (Google)
 -->
 
-***作者*** Todd Neal (AWS), Matthias Bertschy (ARMO), Sergey Kanzhelev (Google), Gunju Kim (NAVER), Shannon Kularathna (Google)
-
-<!-- 
-This post explains how to use the new sidecar feature, which enables restartable init containers and is available in alpha in Kubernetes 1.28. We want your feedback so that we can graduate this feature as soon as possible. 
+<!--
+This post explains how to use the new sidecar feature, which enables restartable init containers and is available in alpha in Kubernetes 1.28. We want your feedback so that we can graduate this feature as soon as possible.
 -->
-本文介绍如何使用新的边车特性，该特性允许设置可重新启动的 Init 容器，并已在 Kubernetes 1.28 中以 Alpha 状态提供。我们希望听取你的反馈，以便尽快将此功能推进到毕业阶段。
+本文介绍了如何使用新的边车（Sidecar）功能，该功能支持可重新启动的 Init 容器，
+并且在 Kubernetes 1.28 以 Alpha 版本发布。我们希望得到你的反馈，以便我们尽快完成此功能。
 
-<!-- 
+<!--
 The concept of a “sidecar” has been part of Kubernetes since nearly the very beginning. In 2015, sidecars were described in a [blog post](/blog/2015/06/the-distributed-system-toolkit-patterns/) about composite containers as additional containers that “extend and enhance the ‘main’ container”. Sidecar containers have become a common Kubernetes deployment pattern and are often used for network proxies or as part of a logging system. Until now, sidecars were a concept that Kubernetes users applied without native support. The lack of native support has caused some usage friction, which this enhancement aims to resolve.
- -->
-“边车（Sidecar）” 的概念几乎从一开始就是 Kubernetes 的一部分。
-2015 年，一篇关于边车容器的 [博客文章](/blog/2015/06/the-distributed-system-toolkit-patterns/) 将边车描述为“扩展和增强‘主’容器”的附加容器。
+-->
+“边车”的概念几乎从一开始就是 Kubernetes 的一部分。在 2015 年，
+一篇关于复合容器的[博客文章（英文）](/blog/2015/06/the-distributed-system-toolkit-patterns/)将边车描述为“扩展和增强 ‘main’ 容器”的附加容器。
 边车容器已成为一种常见的 Kubernetes 部署模式，通常用于网络代理或作为日志系统的一部分。
-到目前为止，边车一直是 Kubernetes 用户在缺少原生支持的情况下应用的概念。
-缺乏原生支持也导致了一些使用摩擦，此增强功能旨在解决这些问题。
+到目前为止，边车已经成为 Kubernetes 用户在没有原生支持情况下使用的概念。
+缺乏原生支持导致了一些使用摩擦，此增强功能旨在解决这些问题。
 
-<!-- 
-## What are sidecar containers in 1.28? 
+<!--
+## What are sidecar containers in 1.28?
 -->
-## 在 Kubernetes 1.28 中的边车容器是什么？
+## 在 Kubernetes 1.28 中的边车容器是什么？  {#what-are-sidecar-containers-in-1-28}
 
-<!-- 
-Kubernetes 1.28 adds a new `restartPolicy` field to [init containers](/docs/concepts/workloads/pods/init-containers/) that is available when the `SidecarContainers` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled. 
+<!--
+Kubernetes 1.28 adds a new `restartPolicy` field to [init containers](/docs/concepts/workloads/pods/init-containers/) that is available when the `SidecarContainers` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled.
 -->
-Kubernetes 1.28 在 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/) 
-中添加了一个新的 `restartPolicy` 字段，该字段可以在 `SidecarContainers` 
-[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 启用时使用。
+Kubernetes 1.28 在 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)中添加了一个新的 `restartPolicy` 字段，
+该字段在 `SidecarContainers` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)启用时可用。
 
 ```yaml
 apiVersion: v1
@@ -58,187 +57,177 @@ spec:
   ...
 ```
 
-<!-- 
-The field is optional and, if set, the only valid value is Always. Setting this field changes the behavior of init containers as follows: 
+<!--
+The field is optional and, if set, the only valid value is Always. Setting this field changes the behavior of init containers as follows:
 -->
-该字段是可选的，如果设置，则唯一有效的值为 Always。设置此字段会更改 Init 容器的行为，如下所示：
-
-<!-- 
-- The container restarts if it exits
-- Any subsequent init container starts immediately after the [startupProbe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes) has successfully completed instead of waiting for the restartable init container to exit
-- The resource usage calculation changes for the pod as restartable init container resources are now added to the sum of the resource requests by the main containers 
--->
-- 如果容器退出则重新启动
-- 所有后续的 Init 容器在 [startupProbe](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes) 
-成功完成后立即启动，而不是等待可重新启动的 Init 容器退出
-- Pod 的资源使用计算发生变化，因为可重新启动的 Init 容器资源现在添加到主容器的资源请求总和中
+该字段是可选的，如果对其设置，则唯一有效的值为 Always。设置此字段会更改 Init 容器的行为，如下所示：
 
 <!--
-[Pod termination](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) continues to only depend on the main containers. An init container with a `restartPolicy` of `Always` (named a sidecar) won't prevent the pod from terminating after the main containers exit. 
+- The container restarts if it exits
+- Any subsequent init container starts immediately after the [startupProbe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes) has successfully completed instead of waiting for the restartable init container to exit
+- The resource usage calculation changes for the pod as restartable init container resources are now added to the sum of the resource requests by the main containers
 -->
-[Pod 终止](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) 继续只根据主容器来判定。 
-`restartPolicy` 为 `Always` 的所有 Init 容器（称为 Sidecar）不会阻止 Pod 在主容器退出后进入终止状态。
+- 如果容器退出则会重新启动
+- 任何后续的 Init 容器在 [startupProbe](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes)
+  成功完成后立即启动，而不是等待可重新启动 Init 容器退出
+- 由于可重新启动的 Init 容器资源现在添加到主容器的资源请求总和中，所以 Pod 使用的资源计算发生了变化。
 
+<!--
+[Pod termination](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) continues to only depend on the main containers. An init container with a `restartPolicy` of `Always` (named a sidecar) won't prevent the pod from terminating after the main containers exit.
+-->
+[Pod 终止](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)继续仅依赖于主容器。
+`restartPolicy` 为 `Always` 的 Init 容器（称为边车）不会阻止 Pod 在主容器退出后终止。
 
-<!-- 
-The following properties of restartable init containers make them ideal for the sidecar deployment pattern: 
+<!--
+The following properties of restartable init containers make them ideal for the sidecar deployment pattern:
 -->
 可重新启动的 Init 容器的以下属性使其非常适合边车部署模式：
 
-<!-- 
+<!--
 - Init containers have a well-defined startup order regardless of whether you set a `restartPolicy`, so you can ensure that your sidecar starts before any container declarations that come after the sidecar declaration in your manifest.
 - Sidecar containers don't extend the lifetime of the Pod, so you can use them in short-lived Pods with no changes to the Pod lifecycle.
-- Sidecar containers are restarted on exit, which improves resilience and lets you use sidecars to provide services that your main containers can more reliably consume. 
+- Sidecar containers are restarted on exit, which improves resilience and lets you use sidecars to provide services that your main containers can more reliably consume.
 -->
-- 不管你是否设置了 `restartPolicy`，Init 容器都有明确定义的启动顺序。
-因此，你可以确保清单中的边车容器会在边车声明之后的所有容器之前启动。
-- 边车容器不会延长 Pod 的生命周期，因此你可以在生命期较短的 Pod 中使用
-它们，而无需更改 Pod 生命周期。
-- 边车容器在退出时会重新启动，这提高了可靠性，从而允许你使用边车来为主容器提供更为可靠的服务。
+- 无论你是否设置 `restartPolicy`，初始化容器都有一个明确定义的启动顺序，
+  因此你可以确保你的边车在其所在清单中声明的后续任何容器之前启动。
+- 边车容器不会延长 Pod 的生命周期，因此你可以在短生命周期的 Pod 中使用它们，而不会对 Pod 生命周期产生改变。
+- 边车容器在退出时将被重新启动，这提高了弹性，并允许你使用边车来为主容器提供更可靠地服务。
 
-
-<!-- 
-## When to use sidecar containers 
+<!--
+## When to use sidecar containers
 -->
-## 何时使用边车容器
+## 何时要使用边车容器 {#when-to-use-sidecar-containers}
 
-<!-- 
-You might find built-in sidecar containers useful for workloads such as the following: 
+<!--
+You might find built-in sidecar containers useful for workloads such as the following:
 -->
 你可能会发现内置边车容器对于以下工作负载很有用：
 
-<!-- 
+<!--
 - **Batch or AI/ML workloads**, or other Pods that run to completion. These workloads will experience the most significant benefits.
 - **Network proxies** that start up before any other container in the manifest. Every other container that runs can use the proxy container's services. For instructions, see the [Kubernetes Native sidecars in Istio blog post](https://istio.io/latest/blog/2023/native-sidecars/).
 - **Log collection containers**, which can now start before any other container and run until the Pod terminates. This improves the reliability of log collection in your Pods.
-- **Jobs**, which can use sidecars for any purpose without Job completion being blocked by the running sidecar. No additional configuration is required to ensure this behavior. 
+- **Jobs**, which can use sidecars for any purpose without Job completion being blocked by the running sidecar. No additional configuration is required to ensure this behavior.
 -->
-- **批处理或 AI/ML 工作负载**，或运行一段时间就结束的其他 Pod。这些工作负载将获得最显著的好处。
-- 在清单中的所有其他容器之前启动的**网络代理**。所运行的所有其他容器都可以使用代理容器的服务。
-有关说明，请参阅 [Istio 中的 Kubernetes 原生边车容器博客文章](https://istio.io/latest/blog/2023/native-sidecars/)。
-- **日志收集容器**，现在可以在任何其他容器之前启动并运行至 Pod 终止。这提高了 Pod 中日志收集的可靠性。
-- **作业**，可以将边车用于任何目的，而 Job 的完成不会被正在运行的边车所阻止。无需额外配置即可确保此行为。
+- **批量或 AI/ML 工作负载**，或已运行完成的其他 Pod。这些工作负载将获得最显着的好处。
+- 任何在清单中其他容器之前启动的**网络代理**。所有运行的其他容器都可以使用代理容器的服务。
+  有关说明，请参阅[在 Istio 中使用 Kubernetes 原生 Sidecar](https://istio.io/latest/blog/2023/native-sidecars/)。
+- **日志收集容器**，现在可以在任何其他容器之前启动并运行直到 Pod 终止。这提高了 Pod 中日志收集的可靠性。
+- **Job**，可以将边车用于任何目的，而 Job 完成不会被正在运行的边车阻止。无需额外配置即可确保此行为。
 
-
-<!-- 
-## How did users get sidecar behavior before 1.28? 
+<!--
+## How did users get sidecar behavior before 1.28?
 -->
-## 1.28 之前用户是如何实现边车行为的？
+## 1.28 之前用户如何获得 Sidecar 行为？ {#how-did-users-get-sidecar-behavior-before-1-28}
 
-<!-- 
-Prior to the sidecar feature, the following options were available for implementing sidecar behavior depending on the desired lifetime of the sidecar container: 
+<!--
+Prior to the sidecar feature, the following options were available for implementing sidecar behavior depending on the desired lifetime of the sidecar container:
 -->
-在引入边车特性之前，可以使用以下选项来根据边车容器的预期生命周期来实现边车行为：
+在边车功能出现之前，可以使用以下选项来根据边车容器的所需生命周期来实现边车行为：
 
-<!-- 
+<!--
 - **Lifetime of sidecar less than Pod lifetime**: Use an init container, which provides well-defined startup order. However, the sidecar has to exit for other init containers and main Pod containers to start.
-- **Lifetime of sidecar equal to Pod lifetime**: Use a main container that runs alongside your workload containers in the Pod. This method doesn't give you control over startup order, and lets the sidecar container potentially block Pod termination after the workload containers exit. 
+- **Lifetime of sidecar equal to Pod lifetime**: Use a main container that runs alongside your workload containers in the Pod. This method doesn't give you control over startup order, and lets the sidecar container potentially block Pod termination after the workload containers exit.
 -->
-- **边车的生命周期小于 Pod 生命周期**：使用 Init 容器，这类容器提供明确定义的启动顺序。
-  然而边车必须退出，才能让其他 Init 容器和主 Pod 容器启动。
-- **边车的生命周期与 Pod 生命周期相同**：使用与 Pod 中的工作负载容器一起运行的主容器。此方法无法让你控制启动顺序，并且边车容器可能会在工作负载容器退出后阻止 Pod 终止。
+- **边车的生命周期小于 Pod 生命周期**：使用 Init 容器，它提供明确定义的启动顺序。
+  然而，边车必须退出才能让其他 Init 容器和主 Pod 容器启动。
+- **边车的生命周期等于 Pod 生命周期**：使用与 Pod 中的工作负载容器一起运行的主容器。
+  此方法无法让你控制启动顺序，并让边车容器可能会在工作负载容器退出后阻止 Pod 终止。
 
-
-<!-- 
-The built-in sidecar feature solves for the use case of having a lifetime equal to the Pod lifetime and has the following additional benefits: 
+<!--
+The built-in sidecar feature solves for the use case of having a lifetime equal to the Pod lifetime and has the following additional benefits:
 -->
-内置的边车特性解决了生命周期与 Pod 生命周期相同的场景，并具有以下额外优势：
+内置的边车功能解决了其生命周期与 Pod 生命周期相同的用例，并具有以下额外优势：
 
-
-<!-- 
+<!--
 - Provides control over startup order
-- Doesn’t block Pod termination 
+- Doesn’t block Pod termination
 -->
-- 提供对启动顺序的控制 
-- 不阻止 Pod 终止
+- 提供对启动顺序的控制
+- 不阻碍 Pod 终止
 
-<!-- 
-## Transitioning existing sidecars to the new model 
+<!--
+## Transitioning existing sidecars to the new model
 -->
-## 将现有边车过渡到新模型
+## 将现有边车过渡到新模式 {#transitioning-existing-sidecars-to-the-new-model}
 
-<!-- 
-We recommend only using the sidecars feature gate in [short lived testing clusters](/docs/reference/command-line-tools-reference/feature-gates/#feature-stages) at the alpha stage. If you have an existing sidecar that is configured as a main container so it can run for the lifetime of the pod, it can be moved to the `initContainers` section of the pod spec and given a `restartPolicy` of `Always`. In many cases, the sidecar should work as before with the added benefit of having a defined startup ordering and not prolonging the pod lifetime. 
+<!--
+We recommend only using the sidecars feature gate in [short lived testing clusters](/docs/reference/command-line-tools-reference/feature-gates/#feature-stages) at the alpha stage. If you have an existing sidecar that is configured as a main container so it can run for the lifetime of the pod, it can be moved to the `initContainers` section of the pod spec and given a `restartPolicy` of `Always`. In many cases, the sidecar should work as before with the added benefit of having a defined startup ordering and not prolonging the pod lifetime.
 -->
+我们建议仅在 Alpha 阶段的[短期测试集群](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#feature-stages)中使用边车功能。
+如果你有一个现有的边车，被配置为主容器，以便它可以在 Pod 的生命周期内运行，
+则可以将其移至 Pod 规范的 `initContainers` 部分，并将 `restartPolicy` 指定为 `Always`。
+在许多情况下，边车应该像以前一样工作，并具有定义启动顺序且不会延长 Pod 生命周期的额外好处。
 
-我们建议在 Alpha 阶段仅对[短期存在的测试集群](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#feature-stages)启用边车特性门控。
-如果你已经有一个被配置为主容器的边车，且它可以在 Pod 的整个生命周期内运行，
-则可以将其移至 Pod 规约的 `initContainers` 部分，并将 `restartPolicy` 设置为 `Always`。
-在许多情况下，边车容器能够继续像以前一样工作，并且额外的好处是可以定义启动顺序，并且不会延长 Pod 的生命周期。
-
-
-<!-- 
-## Known issues 
+<!--
+## Known issues
 -->
-##  已知的问题
+## 已知问题 {#known-issues}
 
-<!-- 
-The alpha release of built-in sidecar containers has the following known issues, which we'll resolve before graduating the feature to beta: 
+<!--
+The alpha release of built-in sidecar containers has the following known issues, which we'll resolve before graduating the feature to beta:
 -->
-内置的边车容器的 Alpha 版本具有以下已知问题，我们将在将该功能升级为 Beta 之前解决这些问题：
+内置边车容器的 Alpha 版本具有以下已知问题，我们将在该功能升级为 Beta 之前解决这些问题：
 
-<!-- 
+<!--
 - The CPU, memory, device, and topology manager are unaware of the sidecar container lifetime and additional resource usage, and will operate as if the Pod had lower resource requests than it actually does.
-- The output of `kubectl describe node` is incorrect when sidecars are in use. The output shows resource usage that's lower than the actual usage because it doesn't use the new resource usage calculation for sidecar containers. 
+- The output of `kubectl describe node` is incorrect when sidecars are in use. The output shows resource usage that's lower than the actual usage because it doesn't use the new resource usage calculation for sidecar containers.
 -->
-- CPU、内存、设备和拓扑管理器无法意识到边车容器的生命周期和额外资源使用情况，它们会按照 Pod 资源请求比实际用量低的假设来运行 Pod。
-- 使用边车时，`kubectl describe node` 命令描述的节点的输出不正确。
-  输出显示的资源使用量低于实际使用量，因为它没有计算边车容器的资源使用量。
+- CPU、内存、设备和拓扑管理器不知道边车容器的生命周期和额外的资源使用情况，并且会像 Pod 的资源请求低于实际情况的方式运行。
+- 使用边车时，`kubectl describe node` 的输出不正确。输出显示的资源使用量低于实际使用量，
+  因为它没有对边车容器使用新的资源使用计算方式。
 
-<!-- 
-## We need your feedback! 
+<!--
+## We need your feedback!
 -->
-## 我们需要你的反馈！
+## 我们需要你的反馈！ {#we-need-your-feedback}
 
-<!-- 
-In the alpha stage, we want you to try out sidecar containers in your environments and open issues if you encounter bugs or friction points. We're especially interested in feedback about the following: 
+<!--
+In the alpha stage, we want you to try out sidecar containers in your environments and open issues if you encounter bugs or friction points. We're especially interested in feedback about the following:
 -->
-在 Alpha 阶段，我们希望你在你的环境中尝试边车容器，并在遇到错误或异常点时登记问题。
-我们对以下方面的反馈特别感兴趣：
+在 Alpha 阶段，我们希望你在环境中尝试边车容器，并在遇到错误或摩擦点时提出问题。我们对以下方面的反馈特别感兴趣：
 
-<!-- 
+<!--
 - The shutdown sequence, especially with multiple sidecars running 
 - The backoff timeout adjustment for crashing sidecars 
-- The behavior of Pod readiness and liveness probes when sidecars are running 
+- The behavior of Pod readiness and liveness probes when sidecars are running
 -->
-- 关闭顺序，尤其是多个边车一起运行的时候
-- 边车的重启回退超时时间调整
-- 边车运行时 Pod 就绪性和存活性探针的行为
+- 关闭顺序，尤其是多个边车运行时
+- 碰撞边车的退避超时调整
+- 边车运行时 Pod 就绪性和活性探测的行为
 
-
-<!-- 
-To open an issue, see the [Kubernetes GitHub repository](https://github.com/kubernetes/kubernetes/issues/new/choose). 
+<!--
+To open an issue, see the [Kubernetes GitHub repository](https://github.com/kubernetes/kubernetes/issues/new/choose).
 -->
-要登记问题，请访问 [Kubernetes GitHub 仓库](https://github.com/kubernetes/kubernetes/issues/new/choose)。
+要提出问题，请参阅 [Kubernetes GitHub 存储库](https://github.com/kubernetes/kubernetes/issues/new/choose)。
 
-<!-- 
-## What’s next? 
+<!--
+## What’s next?
 -->
-## 下一步是什么？
+## 接下来是什么？ {#what-s-next}
 
-<!-- 
-In addition to the known issues that will be resolved, we're working on adding termination ordering for sidecar and main containers. This will ensure that sidecar containers only terminate after the Pod's main containers have exited. 
+<!--
+In addition to the known issues that will be resolved, we're working on adding termination ordering for sidecar and main containers. This will ensure that sidecar containers only terminate after the Pod's main containers have exited.
 -->
-除了要解决的已知问题之外，我们正在努力为边车和主容器添加终止顺序。终止顺序能够确保边车容器仅在 Pod 的主容器退出后才终止。
+除了将要解决的已知问题之外，我们正在努力为边车和主容器添加终止顺序。这将确保边车容器仅在 Pod 主容器退出后终止。
 
-
-<!-- 
-We’re excited to see the sidecar feature come to Kubernetes and are interested in feedback. 
+<!--
+We’re excited to see the sidecar feature come to Kubernetes and are interested in feedback.
 -->
-我们很高兴看到 Kubernetes 引入了边车特性，并对反馈感兴趣。
+我们很高兴看到 Kubernetes 引入了边车功能，并期望得到反馈。
 
-<!-- 
-## Acknowledgements 
+<!--
+## Acknowledgements
 -->
-## 致谢
+## 致谢 {#acknowledgements}
 
-<!-- 
-Many years have passed since the original KEP was written, so we apologize if we omit anyone who worked on this feature over the years. This is a best-effort attempt to recognize the people involved in this effort. 
+<!--
+Many years have passed since the original KEP was written, so we apologize if we omit anyone who worked on this feature over the years. This is a best-effort attempt to recognize the people involved in this effort.
 -->
-自最初的 KEP 编写以来已经过去了很多年，因此如果我们漏掉了多年来致力于此特性的相关人员，请接受我们的道歉。我们尽最大努力去认可参与这项工作的人们。
+自从最初的 KEP 编写以来已经过去了很多年，因此如果我们遗漏了多年来致力于此功能的任何人，我们将深表歉意。
+这也是识别该功能参与者的最大限度努力。
 
-
-<!-- 
+<!--
 - [mrunalp](https://github.com/mrunalp/) for design discussions and reviews
 - [thockin](https://github.com/thockin/) for API discussions and support thru years
 - [bobbypage](https://github.com/bobbypage) for reviews
@@ -251,33 +240,31 @@ Many years have passed since the original KEP was written, so we apologize if we
 - [alculquicondor](https://github.com/Alculquicondor) for feedback on addressing the version skew of the scheduler
 - [wojtek-t](https://github.com/Wojtek-t) for PRR review of a KEP
 - [ahg-g](https://github.com/ahg-g) for reviewing the scheduler portion of a KEP
-- [adisky](https://github.com/Adisky) for the Job completion issue 
+- [adisky](https://github.com/Adisky) for the Job completion issue
 -->
+- [mrunalp](https://github.com/mrunalp/) 对于设计的探讨和评论
+- [thockin](https://github.com/thockin/) 多年来对于 API 的讨论和支持
+- [bobbypage](https://github.com/bobbypage) 的审查工作
+- [smarterclayton](https://github.com/smarterclayton) 进行详细审查和反馈
+- [howardjohn](https://github.com/howardjohn) 多年来进行的反馈以及在实施过程中的早期尝试
+- [derekwaynecarr](https://github.com/derekwaynecarr) 和 [dchen1107](https://github.com/dchen1107) 的领导力
+- [jpbetz](https://github.com/Jpbetz) 对 API 和终止排序的设计以及代码审查
+- [Joseph-Irving](https://github.com/Joseph-Irving) 和 [rata](https://github.com/rata) 对于多年前的早期迭代设计和审查
+- [swatisehgal](https://github.com/swatisehgal) 和 [ffromani](https://github.com/ffromani)
+  对于有关资源管理器影响的早期反馈
+- [alculquicondor](https://github.com/Alculquicondor) 对于解决调度程序版本偏差的相关反馈
+- [wojtek-t](https://github.com/Wojtek-t) 对于 KEP 的 PRR 进行审查
+- [ahg-g](https://github.com/ahg-g) 对于 KEP 的调度程序部分进行审查
+- [adisky](https://github.com/Adisky) 处理了 Job 完成问题
 
-- [mrunalp](https://github.com/mrunalp/) 参与了设计讨论和评审 
-- [thockin](https://github.com/thockin/) 多年来的 API 讨论和支持 
-- [bobbypage](https://github.com/bobbypage) 的评审
-- [smarterclayton](https://github.com/smarterclayton) 的细致评审和反馈
-- [howardjohn](https://github.com/howardjohn) 多年来的反馈以及在实现过程中的早期尝试
-- [derekwaynecarr](https://github.com/derekwaynecarr) 和 [dchen1107](https://github.com/dchen1107) 的领导
-- [jpbetz](https://github.com/Jpbetz) 对 API 和终止排序的设计以及代码评审
-- [Joseph-Irving](https://github.com/Joseph-Irving) 和 [rata](https://github.com/rata) 参与多年前的早期迭代设计和评审
-- [swatisehgal](https://github.com/swatisehgal) 和 [ffromani](https://github.com/ffromani) 针对有关资源管理器影响所给出的早期反馈 
-- [alculquicondor](https://github.com/Alculquicondor) 针对与调度程序版本偏差相关的反馈  - [wojtek-t](https://github.com/Wojtek-t) 对 KEP 的 PRR 的评审
-- [ahg-g](https://github.com/ahg-g) 对 KEP 的调度器部分的评审
-- [adisky](https://github.com/Adisky) 解决作业完成问题
-
-
-
-<!-- 
-## More Information 
+<!--
+## More Information
 -->
-## 更多信息
+## 更多内容 {#more-information}
 
-<!-- 
+<!--
 - Read [API for sidecar containers](/docs/concepts/workloads/pods/init-containers/#api-for-sidecar-containers) in the Kubernetes documentation
-- Read the [Sidecar KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/753-sidecar-containers/README.md) 
+- Read the [Sidecar KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/753-sidecar-containers/README.md)
 -->
-- 阅读 Kubernetes 文档中的[边车容器 API](/zh-cn/docs/concepts/workloads/pods/init-containers/#api-for-sidecar-containers) 
-- 阅读 [Sidecar KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/753-sidecar-containers/README.md)
-
+- 阅读 Kubernetes 文档中的[边车容器 API](/zh-cn/docs/concepts/workloads/pods/init-containers/#api-for-sidecar-containers)
+- 阅读[边车 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/753-sidecar-containers/README.md)