他们可以包含并运行实用工具，但是出于安全考虑，时不建议在应用程序容器镜像中包含这些实用工具的。
特们可以包含实用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python、dig这样的工具
应用程序镜像可以分离出创建和部署的角色，而没有必要联合他们构建一个单独的镜像。
Init容器使用Linux Namespace，所以相对应用程序容器来说，具有不同的文件系统视图。因此，他们能够具有访问Secret的权限，而应用程序容器则不能。实现分权限来治理。例如，有一个文件夹里面只有一个文件是main容器要用到的，但是又不希望main容器有这个文件夹的访问权限，于是通过init容器来访问该文件，并且把该文件复制到main容器中。
他们必须在应用程序容器启动之前运行完成，而应用程序容器时并行运行的，所以，Init容器能够提供一种简单的阻塞或延迟应用容器启动的方法，直到满足了一系列应用容器启动的先决条件。例如我们有两个容器，一个放数据库，一个放应用服务，服务要在数据库启动之后启动，访问才不会报错，那么此时我们可以在应用服务容器的init containers中设置一个条件，用于检测数据库容器是否完成启动，如果数据库完成启动了，则应用服务容器可以正常启动。如下图所示：

Init Contianers实验

下面我们通过实际例子来进一步认识init containers。

# init-pod.yaml
# author: 攻城狮白玉
apiVersion: v1
kind: Pod
metadata:
  name: baiyu-pod
  namespace: baiyu-learn-k8s
  labels:
    app: baiyu-app
    version: v1
spec:
  containers:
    - name: baiyu-app-container
      image: busybox:1.32
      command: ['sh', '-c', 'echo The app is running && sleep 3600']
  initContainers:
    - name: init-baiyu-service
      image: busybox:1.32
      command: ['sh', '-c','until nslookup baiyu-service; do echo waiting for baiyu-service; sleep 2;done;']
    - name: init-baiyu-db
      image: busybox:1.32
      command: ['sh', '-c', 'until nslookup baiyu-db; do echo waiting for baiyu-db; sleep 2; done;']

上面的yaml，运行了一个pod。里面有一个main container，有两个init container

kubectl create -f init-pod.yaml

然后执行kubectl get pod -n baiyu-learn-k8s -o wide -w查看容器状态

此时无论多久，上面这个容器都不会变成running状态的。这是因为我们写了两个init container的条件没有满足。

第一个init container里面，我们执行了下面这句命令，表示在我们能解析到有这个baiyu-service名称的网络服务就打破循环。

until nslookup baiyu-service; 
do 
echo waiting for baiyu-service; 
sleep 2;
done;

此处补充个小知识点，便是Linux中until的用法。

until跟while类似，都是一个固定循环。

但是until跟while又有不同，则是它们的条件满足不同。

until是直到条件为真时，打破循环。而while是条件为真时一直循环，条件为假时打破循环。

此时，我们通过命令

kubectl logs baiyu-pod -n baiyu-learn-k8s --container init-baiyu-service

查看pod中的init-baiyu-service容器的日志，可以发现它一直在循环检测服务是否起来

为了满足我们init-pod中的init container的条件，我们准备了以下脚本实现两个service，用于满足init C的条件。

# init-service.yaml
# author: 攻城狮白玉
kind: Service
apiVersion: v1
metadata:
  name: baiyu-service
  namespace: baiyu-learn-k8s
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
---
kind: Service
apiVersion: v1
metadata:
  name: baiyu-db
  namespace: baiyu-learn-k8s
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

执行命令启动脚本kubectl apply -f init-service.yaml

使用kubectl get pod -n baiyu-learn-k8s -o wide -w查看我们的pod的状态。结果如下图所示，在两个init容器执行完成之后，main 容器进行执行，最终Pod完成启动Pod状态变为Running

特殊说明

在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化（网络和数据卷初始化是在pause中启动的）之后启动。每个容器必须在下一个容器启动之前成功退出。
如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。然而，如果Pod的restartPolicy设置为Always，Init容器失败时会使用RestartPolicy策略
在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会再Service中进行聚集。正在初始化中的Pod处于Pending状态，但应该会将Initializing状态设置为true
如果Pod重启，所有Init容器必须重新执行。
对于Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的image字段等价于重启该Pod。
Init容器具有应用容器的所有字段，除了readinessProbe，因为Init容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中强制执行。
在Pod中的每个app和Init容器的名称必须要唯一；与任何其他容器共享同一个名称，会在验证时抛出错误。
Init容器执行的效果应该是幂等的。

总结

本文介绍了k8s整体容器的生命周期以及Init Container的基本概念和作用，并通过一个实战例子进一步加深了各位同学对init Containers的理解。限于篇幅，并没有把容器的生命周期所有知识点写完，下一篇我会介绍容器生命周期的两个探针，readness和liveness。以及启停时的动作钩子