linuxea:kubernetes pod生命周期(6)

对于一个Pod而言,从开始到结束,要经过很多点
初始化则在其中,而初始化也需要一定的时间,如:Dockerfile中的ENTRYPOINT脚本,此脚本也需要运行时间,所谓的秒级启动,可能不包含这些,简述pod什么周期,如下图

其中,在容器内通常运行一个进程,而在pod中通常运行一个容器。在pod中的主容器运行之前是需要做一些环境设定,比如init-containers,在主容器启动之前,会运行一个环境初始化的容器,运行完成后就退出,并且初始化容器不单单只会是一个,多个初始化容器之间是串行执行的,当最后一个初始化容器执行完成并且退出后则主容器启动。
在主容器启动时,也会进行环境初始化,如一些文件展开,启动服务等。
在主容器刚刚启动后,用户可以手动嵌入做一些操作Post start,执行完成则退出。
在主容器结束前,也可以做一些操作pre stop,这种做一些钩子来实现启动前的预设和结束后的清理。

在主容器执行的过程中,还可以做一些操作,在post start 完成后。如,健康状态监测。
liveness probe : 存活状态监测。
readiness probe:就绪性状态检测。

  • 存活探测

在kubernetes中是有两种探测,而Docker中则没有存活探测,因为如果docker不存活则结束,而在kubernetes中则不是,一个pod中存在多个容器,一个容器结束了,而pod则不存在问题的。为了探测某一个特定容器,特别是主容器是否运行正常,则需要存活性探测

  • probe

无论哪一种probe都支持三种探测行为。
第一种则是自定义操作
第二种向指定的套接字发请求
第三种向指定的http发请求,如:get响应码

然而,pod从创建到结束之前,一定处于某种状态之中。
状态如下:
状态:Pending,调度尚未完成的挂起
running:运行状态
Failed:失败.
Succeeded:成功
Unknown:未知状态。pod的状态是API server与运行pod节点的kubelet通信来获取节点信息的, 如果kubelet本身故障,就得不到信息,Unknown

  • 创建pod过程

创建pod时候,请求会提交给apiserver,apiserver将请求的目标状态保存在etcd中,而后apiserver请求scheduler(scheduler负责挑选节点运行pod),调度成功则保存在etcd中,调度信息会更新到etcd的pod资源中的状态资源中。一旦信息存储在etcd中更新后,被调度节点(挑选的NODE)kubelet通过apiserver中的状态变化得知任务下发详情,此刻kubelet通过apiserver会拿到此前用户提交的资源创建清单,根据清单在当前节点上运行或者创建启动这个pod,如果运行或者创建成功或者失败, 它的当前节点状态会发回apiserver,apiserver随后存储在etcd当中.如下图:

现在,我们知道在pod的什么周期中的几种重要行为: 初始化容器,容器探测(liveness,readiness ),但是如果容器挂了又是如何处理的

restartPolicy

一旦pod中的容器挂了,则会有如下状态
Always::重启,延迟重启

  • 一旦某个pod被调度到某个节点后,只要这个节点在,此pod便不会被重新调度,只会进行重启

其中,每隔一段时间,就会向liveness probereadiness probe发送探测 ,一旦故障,故障之后的操作取决于restartPolicy的状态
Onfailure:只有状态为错误才重启
Never: 不重启
Default

终止容器

在删除一个pod时候,并不会直接Kill掉。
其中,当提交一个termination时,会向pod内的每一个容器,发送一个终止信号。而后pod内的容器会进行正常终止,但是这个正常终止并非无限期,他有一个时间宽限段,默认30秒(可另行指定),一旦在这个宽限的时间内没有终止,将会发送终止信号,强行终止
默认情况下,所有删除在30秒内都是正常的。
参考:https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods

0 分享

您可以选择一种方式赞助本站

支付宝扫码赞助

支付宝扫码赞助

日期: 2018-09-09分类: kubernetes

标签: kubernetes

发表评论