Skip to content

Commit baf6b51

Browse files
authored
Merge pull request #42575 from windsonsea/initcy
[zh] sync init-containers.md
2 parents 3e2552e + 74911b8 commit baf6b51

File tree

3 files changed

+137
-2
lines changed

3 files changed

+137
-2
lines changed

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

Lines changed: 77 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -492,12 +492,87 @@ Init 容器一直重复失败。
492492
与任何其它容器共享同一个名称,会在校验时抛出错误。
493493

494494
<!--
495-
### Resources
495+
#### API for sidecar containers
496+
-->
497+
#### 边车容器 API {#api-for-sidecar-containers}
498+
499+
{{< feature-state for_k8s_version="v1.28" state="alpha" >}}
500+
501+
<!--
502+
Starting with Kubernetes 1.28 in alpha, a feature gate named `SidecarContainers`
503+
allows you to specify a `restartPolicy` for init containers which is independent of
504+
the Pod and other init containers. Container [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe)
505+
can also be added to control their lifecycle.
506+
-->
507+
Kubernetes 自 1.28 版本起引入了一个名为 `SidecarContainers` 的 Alpha 特性门控,
508+
允许你为 Init 容器指定独立于 Pod 和其他 Init 容器的 `restartPolicy`
509+
你还可以添加容器[探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe)来控制
510+
Init 容器的生命周期。
511+
512+
<!--
513+
If an init container is created with its `restartPolicy` set to `Always`, it will
514+
start and remain running during the entire life of the Pod, which is useful for
515+
running supporting services separated from the main application containers.
516+
517+
If a `readinessProbe` is specified for this init container, its result will be used
518+
to determine the `ready` state of the Pod.
519+
-->
520+
如果 Init 容器被创建时 `restartPolicy` 设置为 `Always`,则 Init 容器将启动并在整个 Pod
521+
的生命期内保持运行,这对于运行与主应用容器分离的支持服务非常有用。
522+
523+
如果为该 Init 容器指定了 `readinessProbe`,则其结果将用于确定 Pod 的 `ready` 状态。
524+
525+
<!--
526+
Since these containers are defined as init containers, they benefit from the same
527+
ordering and sequential guarantees as other init containers, allowing them to
528+
be mixed with other init containers into complex Pod initialization flows.
529+
530+
Compared to regular init containers, sidecar-style init containers continue to
531+
run and the next init container can begin starting once the kubelet has set
532+
the `started` container status for the sidecar-style init container to true.
533+
That status either becomes true because there is a process running in the
534+
container and no startup probe defined, or
535+
as a result of its `startupProbe` succeeding.
536+
-->
537+
由于这些容器以 Init 容器的形式定义,所以它们具有与其他 Init 容器相同的按序执行和顺序保证优势,
538+
从而允许使用这些容器与其他 Init 容器混合在一起构造复杂的 Pod 初始化流程。
539+
540+
与常规的 Init 容器相比,只要 kubelet 将边车风格的 Init 容器的 `started` 容器状态设置为 true,
541+
边车风格的 Init 容器会继续运行,下一个 Init 容器可以开始启动。
542+
到达该状态的前提是,要么需要容器中有进程正在运行且未定义启动探针,要么其 `startupProbe` 的结果是成功的。
543+
544+
<!--
545+
This feature can be used to implement the sidecar container pattern in a more
546+
robust way, as the kubelet always restarts a sidecar container if it fails.
547+
548+
Here's an example of a Deployment with two containers, one of which is a sidecar:
549+
-->
550+
此特性可用于以更稳健的方式实现边车容器模式,这是因为如果某个边车容器失败,kubelet 总会重新启动它。
551+
552+
以下是一个具有两个容器的 Deployment 示例,其中一个是边车:
553+
554+
{{% codenew language="yaml" file="application/deployment-sidecar.yaml" %}}
555+
556+
<!--
557+
This feature is also useful for running Jobs with sidecars, as the sidecar
558+
container will not prevent the Job from completing after the main container
559+
has finished.
560+
561+
Here's an example of a Job with two containers, one of which is a sidecar:
562+
-->
563+
此特性也可用于运行带有边车的 Job,因为在主容器完成后,边车容器不会阻止 Job 完成。
564+
565+
以下是一个具有两个容器的 Job 示例,其中一个是边车:
566+
567+
{{% codenew language="yaml" file="application/job/job-sidecar.yaml" %}}
568+
569+
<!--
570+
#### Resource sharing within containers
496571
497572
Given the ordering and execution for init containers, the following rules
498573
for resource usage apply:
499574
-->
500-
### 资源 {#resources}
575+
#### 容器内的资源共享 {#resource-sharing-within-containers}
501576

502577
在给定的 Init 容器执行顺序下,资源使用适用于如下规则:
503578

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
apiVersion: apps/v1
2+
kind: Deployment
3+
metadata:
4+
name: myapp
5+
labels:
6+
app: myapp
7+
spec:
8+
replicas: 1
9+
selector:
10+
matchLabels:
11+
app: myapp
12+
template:
13+
metadata:
14+
labels:
15+
app: myapp
16+
spec:
17+
containers:
18+
- name: myapp
19+
image: alpine:latest
20+
command: ['sh', '-c', 'echo "logging" > /opt/logs.txt']
21+
volumeMounts:
22+
- name: data
23+
mountPath: /opt
24+
initContainers:
25+
- name: logshipper
26+
image: alpine:latest
27+
restartPolicy: Always
28+
command: ['sh', '-c', 'tail /opt/logs.txt']
29+
volumeMounts:
30+
- name: data
31+
mountPath: /opt
32+
volumes:
33+
- name: data
34+
emptyDir: {}
Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
apiVersion: batch/v1
2+
kind: Job
3+
metadata:
4+
name: myjob
5+
spec:
6+
template:
7+
spec:
8+
containers:
9+
- name: myjob
10+
image: alpine:latest
11+
command: ['sh', '-c', 'echo "logging" > /opt/logs.txt']
12+
volumeMounts:
13+
- name: data
14+
mountPath: /opt
15+
initContainers:
16+
- name: logshipper
17+
image: alpine:latest
18+
restartPolicy: Always
19+
command: ['sh', '-c', 'tail /opt/logs.txt']
20+
volumeMounts:
21+
- name: data
22+
mountPath: /opt
23+
restartPolicy: Never
24+
volumes:
25+
- name: data
26+
emptyDir: {}

0 commit comments

Comments
 (0)