kubernetes之初始化容器

参考：https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

初始化容器是什么？

在kubernetes中，一个pod可以包含多个容器，其中的init container，顾名思义主要负责初始化工作，一个pod也可以包含多个init container。后文统一用"初始化容器"表示"init container"。初始化容器也是容器，在pod的定义中，如果将"containers"改成"initContainers"，那么这个数组内定义的所有容器就都是初始化容器，定义初始化容器与普通应用容器的语法相同。但是，初始化容器不支持readiness类型探针，这个很容易理解，初始化容器主要负责初始化工作，在它没有运行完成之前pod一定处于未就绪状态(unready)，所以readiness类型探针一定会诊断失败，没有意义。另外初始化容器在资源请求与限制方面与普通的应用容器有细微差别，后文详细描述。

初始化容器先于普通应用容器执行，如果pod有多个初始化容器，那么它们按定义的顺序逐个执行，并且前一个必需执行成功后一个才可以执行，所有的初始化容器执行成功后，普通应用容器才可以执行。当初始化容器执行失败时，如果restart policy是OnFailure或者Always，那么会重复执行失败的初始化容器一直到成功，如果restart policy是Never，则不会重启失败的初始化容器。如果初始化容器执行成功，那么无论restart policy是什么，即使是Always，也不会再次被重启。

初始化容器的状态可以通过pod的.status.initContainerStatuses字段查看，它的值是一个数组，分别表示每个初始化容器的状态。数组中每个成员的结果与表示普通应用容器状态的结构一样，字段含义相同。

初始化容器有什么用？

在开发一个程序时，通常初化代码与主体业务代码放置在同一个程序中。为什么kubernetes提供初始化容器这种功能，将初始化工作从普通容器中隔离出来？这种特性有什么用呢？初始化容器与普通容器有各自独立的image，本质上是将初始化逻辑与主体业务逻辑分离并放置在不同的image中，以下是初始化容器的主要用处：

• 初始化容器可以包含不能随普通容器一起发布出去的敏感信息。
• 初始化容器可以包含用户自定义的代码、工具，如sed、awk、python等方便完成初始化、设置工作。
• 因为初始化逻辑与主体业务逻辑分布在不同的image中，因此image构建者与主体业务逻辑开发者可以各自独立的工作。
• 初始化容器使用Linux namesp