初始化容器
在很多应用场景中，应用在启动之前都需要进行如下初始化操作。
- ◎ 等待其他关联组件正确运行（例如数据库或某个后台服务）。
- ◎ 基于环境变量或配置模板生成配置文件。
- ◎ 从远程数据库获取本地所需配置，或者将自身注册到某个中央数据库中。
- ◎ 下载相关依赖包，或者对系统进行一些预配置操作。
一、InitContainer-初始化容器的用途
一般生产容器不会使用多余的工具，比如wget、git等
- Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码；
- Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低；
- Init容器可以以root身份运行，执行一些高权限命令；
- Init容器相关操作执行完成以后即退出，不会给业务容器带来安全隐患。
在主应用启动之前，做一些初始化的操作，比如创建文件、修改内核参数、等待依赖程序启动或其他需要在主程序启动之前需要做的工作。
二、初始化容器和PostStart区别
-
PostStart：依赖主应用的环境，比如wget，没有这个命令会失败。而且并不一定先于Command运行
-
InitContainer：不依赖主应用的环境，可以有更高的权限和更多的工具，一定会在主应用启动之前完成
三、初始化容器和普通容器的区别
Init 容器与普通的容器非常像，除了如下几点：
- 上一个初始化容器运行成功状态，才能运行到下一个初始化容器，如失败则会停止。直到所有初始化容器成功完成，才能启动主容器。
- 它们总是运行到完成，上一个运行完成才会运行下一个；
- 如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止，但是Pod 对应的 restartPolicy 值为 Never，Kubernetes 不会重新启动 Pod。
- Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe
四、初始化容器配置示例
编写初始化容器yaml文件
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: test-initname: test-initnamespace: kube-public
spec:replicas: 2selector:matchLabels:app: test-inittemplate:metadata<