Init Container的实战应用

****k8s Init Container的实战应用！

在很多应用场景中，应用在启动之前都需要进行如下初始化操作，如：
- 等待其他关联组件正确运行（例如数据库或某个后台服务〉。
- 基于环境变量或配置模板生成配置文件。
- 从远程数据库获取本地所需配置，或者将自身注册到某个中央数据库中。
- 下载相关依赖包 ， 或者对系统进行一些预配置操作。

​ Kubernetes v1.3 引入了 一个 Alpha 版本的新特性 init container （在 Kubemetes v1.5 时被更新为 Beta 版本），用于在启动应用容器（ app container ）之前启动一个或多个“初始化 ”容器，完成应用容器所需的预置条件，如图 所示。 Init container 与应用容器本质上是一样的 ，但它们是仅运行一次就结束的任务，并且必须在成功执行完成后，系统才能继续执行下一个容器。根据 Pod 的重启策略（ Res tartPolicy ），当 init container 执行失败，在设置了 Res tartPolicy=Never时， Pod 将会启动失败： 而设置 RestartPolicy=Always 时， Pod 将会被系统自动重启

用Tomcat容器发布WAR包, 应该如何设计？

如果用单容器来解决, 我们很容易想到, 有以下两种方案:
方案一: 把 WAR 包直接放在 Tomcat 镜像的 webapps 目录下，做成一个新的镜像运行起来.
方案二: 只运行 Tomcat 的容器, 将WAR包放在宿主机目录中, 挂载到 Tomcat 容器中的webapp目录中去.

对于方案一, 如果要更新 WAR 包的内容，或者要升级 Tomcat 镜像，就要重新制作一个新的发布镜像，非常麻烦。
方案二也有个问题, 如何让每一台宿主机，都预先准备好这个存储有 WAR 包的目录呢？ 只能再维护一套分布式存储系统或是共享存储了。

有了 Pod 之后，我们又有了第三种解决方案: 把 WAR 包和 Tomcat 分别做成镜像，然后把它们作为一个 Po