pod中state与laststate及kubectl get pod中的status的关联

如果pod拉起容器失败,在pod的json中containerStatuses中可以看到有个lastState的field,如果容器运行正常且之前没有异常退出,这个field是个空值。这里探讨一下pod json中state,lastState及kubectl get po看到pod的status之间的关联。

首先明确containerStatus中的LastTerminationState,这个值即pod json中的lastState的值


如果容器退出了,状态保留在LastTerminationState,state.waiting里值是reason值,这个reason从reasoncache里取出来的。(pod里的container第一次启动后失败,lastState是空值)


研究一下kubelet的这个reasonCache,发现其只在一个地方做了更新,这个update能add能remove。这里看到只有SyncPod的返回值进入到了这个reasoncCache


其中的Update只对StartContainer类型的action才会存储,如下:


这个SyncPod在docker_manager.go中实现,其中将失败原因写到result中,result类别比较多,既包含pause容器的,也包含用户容器的,并且有多种SyncAction的,如下,其中我们只关注startcontainer,原因上面说了,reasonCache里只会存储startcontainer这个action相关的key。


对于启动用户容器,处于backoff阶段的pod拿到的错误原因是crashloopbackoff,不处于backoff阶段的才拿到的真正失败原因(调用栈tryContainerStart -> runContainerInPod -> runContainer -> StartContainer -> docker api)。注意这个result对应的key是startcontainer


去doBackOff里看,拿到的错误即是crashloopbackoff,这就是我们大部分时候看失败的pod,其状态是CrashLoopBackOff。


我们都是通过kubectl看pod的状态,接下来论证kubectl看到的状态就是从pod json中的state字段拿的,


即证明上图中的STATUS中的值为下图中的state.waiting.reason


在pkg/kubectl/resource_printer.go中有如下代码:


在Backoff阶段,把container.State.Waiting.Reason赋给了reason,在随后的输出中,看到reason在第4列,

对应kubectl的输出,


即得证kubectl看到的失败的pod状态就是从pod json中的state字段拿的。至于后面多出来的IP和NODE两列,是因为kubectl加了-o wide

结论:lastState里的reason是上次容器退出的原因,state里的reason如果处于backoff时期,就是CrashLoopBackOff,否则显示是当前容器退出的原因。kubectl get pod 看到的STATUS值即state里的reason值。
  • 4
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值