Merge pull request #42575 from windsonsea/initcy

[zh] sync init-containers.md
This commit is contained in:
Kubernetes Prow Robot 2023-08-20 23:57:22 -07:00 committed by GitHub
commit baf6b51ee0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 137 additions and 2 deletions

View File

@ -492,12 +492,87 @@ Init 容器一直重复失败。
与任何其它容器共享同一个名称,会在校验时抛出错误。
<!--
### Resources
#### API for sidecar containers
-->
#### 边车容器 API {#api-for-sidecar-containers}
{{< feature-state for_k8s_version="v1.28" state="alpha" >}}
<!--
Starting with Kubernetes 1.28 in alpha, a feature gate named `SidecarContainers`
allows you to specify a `restartPolicy` for init containers which is independent of
the Pod and other init containers. Container [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe)
can also be added to control their lifecycle.
-->
Kubernetes 自 1.28 版本起引入了一个名为 `SidecarContainers` 的 Alpha 特性门控,
允许你为 Init 容器指定独立于 Pod 和其他 Init 容器的 `restartPolicy`
你还可以添加容器[探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe)来控制
Init 容器的生命周期。
<!--
If an init container is created with its `restartPolicy` set to `Always`, it will
start and remain running during the entire life of the Pod, which is useful for
running supporting services separated from the main application containers.
If a `readinessProbe` is specified for this init container, its result will be used
to determine the `ready` state of the Pod.
-->
如果 Init 容器被创建时 `restartPolicy` 设置为 `Always`,则 Init 容器将启动并在整个 Pod
的生命期内保持运行,这对于运行与主应用容器分离的支持服务非常有用。
如果为该 Init 容器指定了 `readinessProbe`,则其结果将用于确定 Pod 的 `ready` 状态。
<!--
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.
Compared to regular init containers, sidecar-style init containers continue to
run and the next init container can begin starting once the kubelet has set
the `started` container status for the sidecar-style init container to true.
That status either becomes true because there is a process running in the
container and no startup probe defined, or
as a result of its `startupProbe` succeeding.
-->
由于这些容器以 Init 容器的形式定义,所以它们具有与其他 Init 容器相同的按序执行和顺序保证优势,
从而允许使用这些容器与其他 Init 容器混合在一起构造复杂的 Pod 初始化流程。
与常规的 Init 容器相比,只要 kubelet 将边车风格的 Init 容器的 `started` 容器状态设置为 true
边车风格的 Init 容器会继续运行,下一个 Init 容器可以开始启动。
到达该状态的前提是,要么需要容器中有进程正在运行且未定义启动探针,要么其 `startupProbe` 的结果是成功的。
<!--
This feature can be used to implement the sidecar container pattern in a more
robust way, as the kubelet always restarts a sidecar container if it fails.
Here's an example of a Deployment with two containers, one of which is a sidecar:
-->
此特性可用于以更稳健的方式实现边车容器模式这是因为如果某个边车容器失败kubelet 总会重新启动它。
以下是一个具有两个容器的 Deployment 示例,其中一个是边车:
{{% codenew language="yaml" file="application/deployment-sidecar.yaml" %}}
<!--
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.
Here's an example of a Job with two containers, one of which is a sidecar:
-->
此特性也可用于运行带有边车的 Job因为在主容器完成后边车容器不会阻止 Job 完成。
以下是一个具有两个容器的 Job 示例,其中一个是边车:
{{% codenew language="yaml" file="application/job/job-sidecar.yaml" %}}
<!--
#### Resource sharing within containers
Given the ordering and execution for init containers, the following rules
for resource usage apply:
-->
### 资源 {#resources}
#### 容器内的资源共享 {#resource-sharing-within-containers}
在给定的 Init 容器执行顺序下,资源使用适用于如下规则:

View File

@ -0,0 +1,34 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
labels:
app: myapp
spec:
replicas: 1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: alpine:latest
command: ['sh', '-c', 'echo "logging" > /opt/logs.txt']
volumeMounts:
- name: data
mountPath: /opt
initContainers:
- name: logshipper
image: alpine:latest
restartPolicy: Always
command: ['sh', '-c', 'tail /opt/logs.txt']
volumeMounts:
- name: data
mountPath: /opt
volumes:
- name: data
emptyDir: {}

View File

@ -0,0 +1,26 @@
apiVersion: batch/v1
kind: Job
metadata:
name: myjob
spec:
template:
spec:
containers:
- name: myjob
image: alpine:latest
command: ['sh', '-c', 'echo "logging" > /opt/logs.txt']
volumeMounts:
- name: data
mountPath: /opt
initContainers:
- name: logshipper
image: alpine:latest
restartPolicy: Always
command: ['sh', '-c', 'tail /opt/logs.txt']
volumeMounts:
- name: data
mountPath: /opt
restartPolicy: Never
volumes:
- name: data
emptyDir: {}