@@ -28,8 +28,8 @@ Typically, you only have one app container in a Pod. For example, if you have a
28
28
application that requires a local webserver, the local webserver is a sidecar and the
29
29
web application itself is the app container.
30
30
-->
31
- 通常,一个 Pod 中只有一个应用程序容器 。
32
- 例如,如果你有一个需要本地 Web 服务器的 Web 应用程序 ,
31
+ 通常,一个 Pod 中只有一个应用容器 。
32
+ 例如,如果你有一个需要本地 Web 服务器的 Web 应用 ,
33
33
则本地 Web 服务器以边车容器形式运行,而 Web 应用本身以应用容器形式运行。
34
34
35
35
<!-- body -->
@@ -63,8 +63,8 @@ and other init containers.
63
63
[ 特性门控] ( /zh-cn/docs/reference/command-line-tools-reference/feature-gates/ )
64
64
(该特性自 Kubernetes v1.29 起默认启用),你可以为 Pod 的 ` initContainers `
65
65
字段中列出的容器指定 ` restartPolicy ` 。
66
- 这些可重新启动的** 边车(Sidecar)** 容器独立于其他 Init 容器以及同一 Pod 内的主应用程序容器 ,
67
- 这些容器可以启动、停止和重新启动,而不会影响主应用程序容器和其他 Init 容器。
66
+ 这些可重新启动的** 边车(Sidecar)** 容器独立于其他 Init 容器以及同一 Pod 内的主应用容器 ,
67
+ 这些容器可以启动、停止和重新启动,而不会影响主应用容器和其他 Init 容器。
68
68
69
69
<!--
70
70
You can also run a Pod with multiple containers that are not marked as init or sidecar
@@ -129,6 +129,17 @@ kubelet 启动 `.spec.initContainers` 这一有序列表中的下一个 Init 容
129
129
该状态要么因为容器中有一个正在运行的进程且没有定义启动探针而变为 true,
130
130
要么是其 ` startupProbe ` 成功而返回的结果。
131
131
132
+ <!--
133
+ Upon Pod [termination](/docs/concepts/workloads/pods/pod-lifecycle/#termination-with-sidecars),
134
+ the kubelet postpones terminating sidecar containers until the main application container has fully stopped.
135
+ The sidecar containers are then shut down in the opposite order of their appearance in the Pod specification.
136
+ This approach ensures that the sidecars remain operational, supporting other containers within the Pod,
137
+ until their service is no longer required.
138
+ -->
139
+ 在 Pod [ 终止] ( /zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#termination-with-sidecars ) 时,
140
+ kubelet 会推迟终止边车容器,直到主应用容器已完全停止。边车容器随后将按照它们在 Pod 规约中出现的相反顺序被关闭。
141
+ 这种方法确保了在不再需要边车服务之前这些边车继续发挥作用,以支持 Pod 内的其他容器。
142
+
132
143
<!--
133
144
### Jobs with sidecar containers
134
145
-->
@@ -206,7 +217,7 @@ exchange messages with the app container in a Pod. Any data passing is one-way
206
217
边车容器可以直接与主应用容器交互,因为与 Init 容器一样,
207
218
它们总是与应用容器共享相同的网络,并且还可以选择共享卷(文件系统)。
208
219
209
- Init 容器在主容器启动之前停止,因此 Init 容器无法与 Pod 中的应用程序容器交换消息 。
220
+ Init 容器在主容器启动之前停止,因此 Init 容器无法与 Pod 中的应用容器交换消息 。
210
221
所有数据传递都是单向的(例如,Init 容器可以将信息放入 ` emptyDir ` 卷中)。
211
222
212
223
## 容器内的资源共享 {#resource-sharing-within-containers}
@@ -263,7 +274,7 @@ limit.
263
274
On Linux, resource allocations for Pod level control groups (cgroups) are based on the effective Pod
264
275
request and limit, the same as the scheduler.
265
276
-->
266
- ### Sidecar 容器和 Linux Cgroup {#cgroups}
277
+ ### 边车容器和 Linux Cgroup {#cgroups}
267
278
268
279
在 Linux 上,Pod Cgroup 的资源分配基于 Pod 级别的有效资源请求和限制,这一点与调度器相同。
269
280
0 commit comments