From 9336671ceea6f430b40b0c9fe80f4af94e2a7599 Mon Sep 17 00:00:00 2001
From: "xin.li" <xin.li@daocloud.io>
Date: Wed, 15 May 2024 00:22:47 +0800
Subject: [PATCH] [zh-cn] sync sidecar-containers

Signed-off-by: xin.li <xin.li@daocloud.io>
---
 .../workloads/pods/sidecar-containers.md      | 143 ++++++++++++------
 1 file changed, 99 insertions(+), 44 deletions(-)

diff --git a/content/zh-cn/docs/concepts/workloads/pods/sidecar-containers.md b/content/zh-cn/docs/concepts/workloads/pods/sidecar-containers.md
index 0108f26417..97f576b4fa 100644
--- a/content/zh-cn/docs/concepts/workloads/pods/sidecar-containers.md
+++ b/content/zh-cn/docs/concepts/workloads/pods/sidecar-containers.md
@@ -15,34 +15,78 @@ weight: 50
 <!--
 Sidecar containers are the secondary containers that run along with the main
 application container within the same {{< glossary_tooltip text="Pod" term_id="pod" >}}.
-These containers are used to enhance or to extend the functionality of the main application
-container by providing additional services, or functionality such as logging, monitoring,
+These containers are used to enhance or to extend the functionality of the primary _app
+container_ by providing additional services, or functionality such as logging, monitoring,
 security, or data synchronization, without directly altering the primary application code.
 -->
-边车容器是与主应用容器在同一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中运行的辅助容器。
+边车容器是与**主应用容器**在同一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中运行的辅助容器。
 这些容器通过提供额外的服务或功能（如日志记录、监控、安全性或数据同步）来增强或扩展主应用容器的功能，
 而无需直接修改主应用代码。
 
+<!--
+Typically, you only have one app container in a Pod. For example, if you have a web
+application that requires a local webserver, the local webserver is a sidecar and the
+web application itself is the app container.
+-->
+通常，一个 Pod 中只有一个应用程序容器。
+例如，如果你有一个需要本地 Web 服务器的 Web 应用程序，
+则本地 Web 服务器以边车容器形式运行，而 Web 应用本身以应用容器形式运行。
+
 <!-- body -->
 
 <!--
-## Enabling sidecar containers
+## Sidecar containers in Kubernetes {#pod-sidecar-containers}
 
-Enabled by default with Kubernetes 1.29, a
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) named
-`SidecarContainers` allows you to specify a `restartPolicy` for containers listed in a
-Pod's `initContainers` field. These restartable _sidecar_ containers are independent with
-other [init containers](/docs/concepts/workloads/pods/init-containers/) and main
-application container within the same pod. These can be started, stopped, or restarted
-without affecting the main application container and other init containers.
+Kubernetes implements sidecar containers as a special case of
+[init containers](/docs/concepts/workloads/pods/init-containers/); sidecar containers remain
+running after Pod startup. This document uses the term _regular init containers_ to clearly
+refer to containers that only run during Pod startup.
 -->
-## 启用边车容器   {#enabling-sidecar-containers}
+## Kubernetes 中的边车容器   {#pod-sidecar-containers}
 
-Kubernetes 1.29 默认启用，一个名为 `SidecarContainers`
-的[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)允许你为
-Pod 的 `initContainers` 字段中列出的容器指定 `restartPolicy`。这些可重启的**边车**容器与同一
-Pod 内的其他 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)及主应用容器相互独立。
-边车容器可以在不影响主应用容器和其他 Init 容器的情况下启动、停止或重启。
+Kubernetes 将边车容器作为
+[Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)的一个特例来实现，
+Pod 启动后，边车容器仍保持运行状态。
+本文档使用术语"常规 Init 容器"来明确指代仅在 Pod 启动期间运行的容器。
+
+<!--
+Provided that your cluster has the `SidecarContainers`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled
+(the feature is active by default since Kubernetes v1.29), you can specify a `restartPolicy`
+for containers listed in a Pod's `initContainers` field.
+These restartable _sidecar_ containers are independent from other init containers and from
+the main application container(s) within the same pod.
+These can be started, stopped, or restarted without effecting the main application container
+and other init containers.
+-->
+如果你的集群启用了 `SidecarContainers`
+[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
+（该特性自 Kubernetes v1.29 起默认启用），你可以为 Pod 的 `initContainers`
+字段中列出的容器指定 `restartPolicy`。
+这些可重新启动的**边车（Sidecar）** 容器独立于其他 Init 容器以及同一 Pod 内的主应用程序容器，
+这些容器可以启动、停止和重新启动，而不会影响主应用程序容器和其他 Init 容器。
+
+<!--
+You can also run a Pod with multiple containers that are not marked as init or sidecar
+containers. This is appropriate if the containers within the Pod are required for the
+Pod to work overall, but you don't need to control which containers start or stop first.
+You could also do this if you need to support older versions of Kubernetes that don't
+support a container-level `restartPolicy` field.
+-->
+你还可以运行包含多个未标记为 Init 或边车容器的 Pod。
+如果作为一个整体而言，某个 Pod 中的所有容器都要运行，但你不需要控制哪些容器先启动或停止，那么这种设置是合适的。
+如果你使用的是不支持容器级 `restartPolicy` 字段的旧版本 Kubernetes，你也可以这样做。
+
+<!--
+### Example application {#sidecar-example}
+
+Here's an example of a Deployment with two containers, one of which is a sidecar:
+-->
+### 应用示例   {#sidecar-example}
+
+下面是一个包含两个容器的 Deployment 示例，其中一个容器是边车形式：
+
+{{% code_sample language="yaml" file="application/deployment-sidecar.yaml" %}}
 
 <!--
 ## Sidecar containers and Pod lifecycle
@@ -61,13 +105,13 @@ If a `readinessProbe` is specified for this init container, its result will be u
 to determine the `ready` state of the Pod.
 
 Since these containers are defined as init containers, they benefit from the same
-ordering and sequential guarantees as other init containers, allowing them to
-be mixed with other init containers into complex Pod initialization flows.
+ordering and sequential guarantees as other init containers, allowing them to mix
+sidecar containers with regular init containers for complex Pod initialization flows.
 -->
 如果为此 Init 容器指定了 `readinessProbe`，其结果将用于确定 Pod 的 `ready` 状态。
 
 由于这些容器被定义为 Init 容器，所以它们享有与其他 Init 容器相同的顺序和按序执行保证，
-可以将它们与其他 Init 容器混合在一起，形成复杂的 Pod 初始化流程。
+从而允许将边车容器与常规 Init 容器混合使用，支持复杂的 Pod 初始化流程。
 
 <!--
 Compared to regular init containers, sidecars defined within `initContainers` continue to
@@ -86,45 +130,44 @@ kubelet 启动 `.spec.initContainers` 这一有序列表中的下一个 Init 容
 要么是其 `startupProbe` 成功而返回的结果。
 
 <!--
-Here's an example of a Deployment with two containers, one of which is a sidecar:
+### Jobs with sidecar containers
 -->
-以下是一个具有两个容器的 Deployment 示例，其中一个是边车：
-
-{{% code_sample language="yaml" file="application/deployment-sidecar.yaml" %}}
+### 带边车容器的 Job {#jobs-with-sidecar-containers}
 
 <!--
-This feature is also useful for running Jobs with sidecars, as the sidecar
-container will not prevent the Job from completing after the main container
-has finished.
+If you define a Job that uses sidecar using Kubernetes-style init containers,
+the sidecar container in each Pod does not prevent the Job from completing after the
+main container has finished.
 
 Here's an example of a Job with two containers, one of which is a sidecar:
 -->
-此特性也适用于带有边车的 Job，因为边车容器在主容器完成后不会阻止 Job 的完成。
+如果你定义 Job 时使用基于 Kubernetes 风格 Init 容器的边车容器，
+各个 Pod 中的边车容器不会阻止 Job 在主容器结束后进入完成状态。
 
 以下是一个具有两个容器的 Job 示例，其中一个是边车：
 
 {{% code_sample language="yaml" file="application/job/job-sidecar.yaml" %}}
 
 <!--
-## Differences from regular containers
+## Differences from application containers
 
-Sidecar containers run alongside regular containers in the same pod. However, they do not
+Sidecar containers run alongside _app containers_ in the same pod. However, they do not
 execute the primary application logic; instead, they provide supporting functionality to
 the main application.
 -->
-## 与常规容器的区别   {#differences-from-regular-containers}
+## 与应用容器的区别   {#differences-from-application-containers}
 
-边车容器与同一 Pod 中的常规容器并行运行。不过边车容器不执行主应用逻辑，而是为主应用提供支持功能。
+边车容器与同一 Pod 中的**应用容器**并行运行。不过边车容器不执行主应用逻辑，而是为主应用提供支持功能。
 
 <!--
 Sidecar containers have their own independent lifecycles. They can be started, stopped,
-and restarted independently of regular containers. This means you can update, scale, or
+and restarted independently of app containers. This means you can update, scale, or
 maintain sidecar containers without affecting the primary application.
 
 Sidecar containers share the same network and storage namespaces with the primary
-container This co-location allows them to interact closely and share resources.
+container. This co-location allows them to interact closely and share resources.
 -->
-边车容器具有独立的生命周期。它们可以独立于常规容器启动、停止和重启。
+边车容器具有独立的生命周期。它们可以独立于应用容器启动、停止和重启。
 这意味着你可以更新、扩展或维护边车容器，而不影响主应用。
 
 边车容器与主容器共享相同的网络和存储命名空间。这种共存使它们能够紧密交互并共享资源。
@@ -150,14 +193,21 @@ sidecar containers support [probes](/docs/concepts/workloads/pods/pod-lifecycle/
 边车容器支持[探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe)来控制其生命周期。
 
 <!--
-These containers can interact directly with the main application containers, sharing
-the same network namespace, filesystem, and environment variables. They work closely
-together to provide additional functionality.
+Sidecar containers can interact directly with the main application containers, because
+like init containers they always share the same network, and can optionally also share
+volumes (filesystems).
+
+Init containers stop before the main containers start up, so init containers cannot
+exchange messages with the app container in a Pod. Any data passing is one-way
+(for example, an init container can put information inside an `emptyDir` volume).
 
 ## Resource sharing within containers
 -->
-这些边车容器可以直接与主应用容器进行交互，共享相同的网络命名空间、文件系统和环境变量。
-所有这些容器紧密合作，提供额外的功能。
+边车容器可以直接与主应用容器交互，因为与 Init 容器一样，
+它们总是与应用容器共享相同的网络，并且还可以选择共享卷（文件系统）。
+
+Init 容器在主容器启动之前停止，因此 Init 容器无法与 Pod 中的应用程序容器交换消息。
+所有数据传递都是单向的（例如，Init 容器可以将信息放入 `emptyDir` 卷中）。
 
 ## 容器内的资源共享   {#resource-sharing-within-containers}
 
@@ -204,13 +254,18 @@ for resource usage apply:
 <!--
 Quota and limits are applied based on the effective Pod request and
 limit.
-
-Pod level control groups (cgroups) are based on the effective Pod request and
-limit, the same as the scheduler.
 -->
 配额和限制适用于 Pod 的有效请求和限制值。
 
-Pod 级别的 cgroup 是基于 Pod 的有效请求和限制值，与调度器相同。
+<!--
+### Sidecar containers and Linux cgroups {#cgroups}
+
+On Linux, resource allocations for Pod level control groups (cgroups) are based on the effective Pod
+request and limit, the same as the scheduler.
+-->
+### Sidecar 容器和 Linux Cgroup   {#cgroups}
+
+在 Linux 上，Pod Cgroup 的资源分配基于 Pod 级别的有效资源请求和限制，这一点与调度器相同。
 
 ## {{% heading "whatsnext" %}}