pod生命周期.png
init容器
Pod能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个应用容器启动的init
init容器与普通容器非常像，除了以下两点
init容器总是运行到成功完成为止
每个init容器都必须在下一个init容器启动之前成功完成
如果Pod的init容器失败，kubernetes会不断的重启Pod，直到init容器成功为止，然而，如果Pod对应的restartPolicy为Never，它不会重新启动
init容器的作用
1、他们可以包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中，例如，创建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似sed、awk、python或dig这样的工具
2、应用程序镜像可以分离出创建和部署的角色，而没有必要联合他们构建一个单独的镜像
3、init容器使用linux namespace 所以相对应用程序容器来说具有不同的文件系统视图。因此，他们能够具有访问secrer的权限，而应用程序容器不能
4、他们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运动的，所以init容器能够提供一种简单的阻塞或延迟应用容器的启动方法，直到满足了一组解决条件
示例
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice: sleep 2; done;'] //使用nslookup解析myservice 解析成功则退出。myservice名称与service名称对应
- name: init-mydb
image: busybox
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
---
apiVersion: v1
kind: Service
metadata:
name: myservice
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
name: mydb
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9377
注意事项
1,在pod启动过程中，init容器会按顺序在网络和数据初始化之后启动。每个容器必须在下一个容器启动之前成功退出
2,如果由于运行时或失败退出，将导致容器启动失败，它会根据pod的restartpolicy指定的策略进行重试，然而，如果pod的restartpolicy设置为always，init容器失败时会使用restartpolicy策略
3,在所有的init容器没有成功之前，pod将不会变成ready状态，init容器的端口将不会在service中进行聚集，正在初始化中的pod处于pending状态，但应该将initializing装态设置为true
4,如果pod重启，所有init容器必须重新执行
5,对init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改init容器的image字段等皆与重启该pod
6,init容器具有应用容器所有字段，除了readinessProbe，因为容器无法定义不同于完成(completion)的就绪(rediness)之外的其他状态。这会在验证过程中强制执行
7,在pod中的每个app和init容器的名称必须唯一，与任何其他容器共享同一个名称，会在验证时抛出错误
