pod中state与laststate及kubectl get pod中的status的关联
2017-09-10 17:07
796 查看
如果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值。
首先明确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值。
相关文章推荐
- 使用kubectl delete pods xxx删除对应的pod,提示删除成功,但是立马又回生成一个。为何?
- 使用go-template自定义kubectl get输出
- kubectl get csr 显示No Resources Found的解决记录
- kubernetes集群使用kubectl logs 无法查看node节点pod日志问题
- recvfrom 错误 GetLastError() SOCKET_ERROR 100142008年12月23日 星期二 11:48 A.M.int PASCAL FAR recvfrom( SOCK
- 比较 stm32的 DMA_GetITStatus 和 DMA_GetFlagStatus
- getLastKnownLocation 返回null
- getPhysicalNumberOfCells 与 getLastCellNum的区别
- 对象XMLHttpRequest readyState 和status状态对照(转)
- 关于使用getLastKnownLocation定位报错的问题
- LoadLibrary失敗,GetLastError 返回127錯誤
- get external sdcard status using java reflection
- android getLastNonConfigurationInstance
- [Objective-C]关联(objc_setAssociatedObject、objc_getAssociatedObject、objc_removeAssociatedObjects)
- RobotFramework自动化测试框架-移动手机自动化测试Get Network Connection Status和Set Network Connection Status关键字的使用
- onRetainNonConfigurationInstance和getLastNonConfigurationInstance
- Office 365 Service Communications API operations--Get Historical Status
- Python_cmd的各种实现方法及优劣(subprocess.Popen, os.system和commands.getstatusoutput)
- AFX_MANAGE_STATE(AfxGetStaticModuleState()) 作用
- GetKeyState(), GetAsyncKeystate(), GetKeyboardSlate()