Kubernetes Init Container
在很多场景中，应用在启动之前都需要进行如下初始化操作。
- 等待其他关联组件正确运行（例如数据库或某个后台服务）。
- 基于环境变量或配置模板生成配置文件。
- 从远程数据库获取本地所需配置，或者自身注册到某个中央数据中。
- 下载某个依赖包，或者对系统进行一些预配置操作。
Kubernetes v1.3 引入了一个 Alpha 版本的新特新 init container（在 Kubernetes v1.5 时被更新为 Beta 版本），用于在启动应用容器（app container）之前启动一个或多个 “初始化” 容器，完成应用容器所需的预置条件。Init container 与应用容器本质上一样的，但它们是仅运行一次就结束的任务，而且必须在成功执行完成之后，系统才会继续执行下一个容器。根据 Pod 的重启策略（RestartPolicy），当 init container 执行失败，在设置了 RestartPolicy=Never 时，Pod 将会启动失败；而设置 RestartPolicy=Always 时，Pod 将会被启动自动重启。
v1.8 版本之后，Init Container 特性完全成熟，其定义被放入了 Pod 的 spec.initContainers。
下面以 Nginx 应用为例，在启动 Nginx 之前，通过初始化容器 busybox 为 Nginx 创建一个 index.html 主页文件。这里为 init container 和 Nginx 设置了一个共享的 volume，以提供 Nginx 访问 init container 设置的 index.html。
nginx-init-containers.yaml
apiVersion: v1``kind: Pod``metadata:`` ``name: nginx`` ``annotations:``spec:`` ``initContainers:`` ``- name: ``install`` ``image: busybox`` ``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: {} |
|---|
创建这个 Pod：
$ kubectl apply -f nginx-init-containers.yaml |
|---|
在运行 init container 的过程中，查看 Pod 的状态，可见 init 过程还未完成：
$ kubectl get po nginx``NAME READY STATUS RESTARTS AGE``nginx 0``/1 Init:0``/1 0 23s``# or``$ kubectl get po``NAME READY STATUS RESTARTS AGE``nginx 0``/1 PodInitializing 0 1m |
|---|
在 init container 成功执行完成之后，系统继续期待 Nginx 容器，再次查看 Pod 的状态：
$ kubectl get po nginx``NAME READY STATUS RESTARTS AGE``nginx 1``/1 Running 0 1m |
|---|
查看 Pod 的时间，可以看到系统首先创建并运行 init container 容器（名为 install），成功之后继续创建运行 Nginx 容器：
$ kubectl describe po nginx |
|---|
执行过程 展开源码
启动完成之后，进入 Nginx 容器，可以看到挂载的目录下已经有了 index.html 文件为 init container 所生产，其内容为：
$ kubectl ``exec -it nginx ``cat /usr/share/nginx/html/index``.html |
|---|
执行结果 展开源码
init container 与应用容器的区别如下：
（1）init container 的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个 init container 时，将按顺序逐个运行，并且只有前一个 init container 运行成功之后才能运行后一个 init container。当所有 init container 都成功运行后，Kubernetes 才会初始化 Pod 的各种信息，并开始创建和运行应用容器。
（2）在 init container 的定义中也可以设置资源限制、volume 的使用和安全策略，等等。但资源限制的设置与应用容器略有不同。
- 如果多个 init container 都定义了资源请求/资源限制，则取最大的值作为所有 init container 的资源请求值/资源限制值。
- Pod 的有效 (efective) 资源请求值/资源限制值取以下二者中的较大值。
a）所有应用容器的资源请求值/资源限制值之和。
b）init container 的有效资源请求值/资源限制值。 - 调度算法将基于 Pod 的有效资源请求值/资源限制值进行计算，也就是说 init container 可以为初始化操作预留系统资源，及时后续应用容器无须使用这些资源。
- Pod 的有效 QoS 等级适用于 init container 和应用容器。
- 资源配额和限制将根据 Pod 的有效资源请求/限制，与调度机制一致。
- init container 不能设置 readinessProbe 探针，因为必须在它们成功运行后才能继续运行 Pod 中定义的普通容器。
在 Pod 重新启动（Restart）时，init container 将会重新运行，场景的 Pod 重启场景如下：
- init container 的镜像被更新时，init container 将会重新运行，导致 Pod 重启。仅更新应用容器的进行只会应用容器被重启。
- Pod 的 infrastructure 容器（pause）更新时，Pod 将会重启。
- 若 Pod 中的所有应用容器都停止了，并且 RestartPolicy=Always，则 Pod 将会重启。
