init container 与应用容器在本质上是一样的,但是它们仅是运行一次就结束的任务,并且必须在成功运行完成后,系统才能继续执行下一个容器。 init container 的重启策略建议设置为 OnFailure。
下面是一个以 Nginx 应用为例,在启动 Nginx 之前,通过初始化容器 busybox 为 Nginx 创建一个 index.html 主页文件,这里为 busybox 和Nginx 设置了一个共享的 Volume,以供 Nginx 访问 init container 设置的 index.html。
apiVersion: v1
kind: Pod
meatdate:
name: nginx
spec:
initContainers:
- name: busybox
image: busybox:latest
command:
- wget
- "-o"
- "/work-dir/index.html"
- http://kubernetes.io
volumeMounts:
- name: workdir
mountPath: "/work-dir"
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: workdir
mountPath: "/usr/share/nginx/html"
dnsPolicy: Default
volumes:
- name: workdir
emptyDir: {}
1)init container 必须先于应用容器执行完成,当设置了多个 init container 时,将按照顺序逐个执行,并且只有前一个 init container 执行成功了才能运行下一个。 2)在 init container 的定义中也可以设置资源限制、Volume 的使用和安全策略等 3)init container 不能设置 readinessProbe 探针。
1)如果多个 init container 都设置了资源请求/限制,则以最大的为准 2)如果上一条存在,则 Pod 中的最大资源请求/限制为:所有普通容器资源请求/限制之和和上面的大的为准 3)依据上两条,所以 init container 可以为初始化操作预留系统资源,即使后续容器无需使用这些资源 4)Pod 的有效 QoS 等级适用于 init container 和 应用容器