当我们启动mydb和myservice两个服务后,我们可以看到初始容器完成并且myapp-pod pod被创建.
kubectl create -f services.yaml service/myservice created service/mydb created kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 9m这些示例非常简单但是应该能为你创建自己的初始容器提供一些灵感
行为细节在启动pod的过程中,在存储卷和网络创建以后,初始容器依次创建.上一个容器必须返回成功下一个才能启动,如果由于运行时错误或者其它异常退出,它会依照restartPolicy来重试,然而,如果restartPolicy设置为Always,初始容器实际上使用的是OnFailure策略
如果pod重启了,则所有的初始容器要重新执行
对初始容器的spec的更改仅限于镜像(image)字段的修改,更改了初始容器的镜像字段相当于重启pod
由于初始容器可以被重启,重试和重新执行,因此它里面的代码应当是幂等的,尤其是写入文件到EmptyDirs的代码应当注意文件可能已经存在
容器中的所有初始容器和普通容器名称必须惟一.
资源基于初始容器的执行顺序,以下关于资源的规则适用:
对于特定资源,所有初始容器申请的最高的生效
对于pod,相同资源申请取以下两者较高的一个:
1) 所有普通应用容器申请的资源总和
2) 初始容器申请的生效的资源(上面说到,初始容器申请资源取所有初始容器申请最大的一个)
调度基于生效的初始请求,这就意味着初始容器可以申请预留资源,即便在pod以后的整个生命周期都用不到
pod重启原因一个pod基于以下列出的原因,会重启,重新执行初始容器:
用户更新初始容器的PodSpec导致镜像发生改变.普通应用容器改变只会使应用容器重启
由于restartPolicy被设置为Always,导致所有容器均被中止,强制重启,由于垃圾回收初始容器的初始状态记录丢失