如果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值。