Kubernetes Init Container

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 将会重启。