这篇文章会写得比较泛。
要知道pod的lifecycle，需要事先了解一下kubelet的一些主要组成结构，我已经挑出了一篇不错的blog，可以直接跳转去事先了解一下，ref：
https://blog.csdn.net/jettery/article/details/78891733
大的视角可以使得对kubelet有一个比较泛泛的认识，比如哪些manager发挥了什么样的作用，但实际上于事无补，如果不追踪代码，没有详细了解pod的生命周期发生了何种变化。
当然了，对于pod的资源的管理还有很多refownerance，好学者可以深入controller-manager看看，我这边把statefulset深入了解了一下，其他controller大同小异。
还是先从pod的创建开始吧。
几个重要的前提：
1. 需要事先了解watch机制，kubelet只watch pod的变动，相应的有三种事件类型 ADDED MODIFIED DELETED
2. 类似Deployment和statefulset，都是一种上层资源，他们一般检查副本数来决定自己的状态，同样的，他们也会调用apiserver的接口来创建删除pod
3. 创建pod的步骤比删除pod的逻辑要简单得多，主要是runtimeGC和killcontainer是分开处理pod和container的
还有几个简单玩意，
1. 一个是podCache，它主要靠runtime来获取pod的真实状态，这个玩意还会生成事件驱动PLEG管道使得触发container和sandbox的状态更新
2. 一个是statusManager，它本来没什么状态，全靠kubelet syncPod函数向内注入status信息（包含container和sandbox的status），由这个manager来对比决定是否向apiserver同步status信息
3. 一个是workqueue， 这个queue十分有趣，它是保证kubelet水平触发的重要一环，所有的信息经由dispatch到具体的函数后，由podWorker来处理每个pod流程，无论处理成功还是失败，都会将它扔到workqueue内，区别是，处理失败的pod会延时10s再enqueue
那么创建pod的思路就简单明了了。
1. kubelet收到ADD pod的操作 并被dispatch到 HandlePodAdditions函数处理pod的创建过程
2. 在syncPod时，会由podCache内的status生成一个状态从而同步到apiserver，由于此时啥也没有，只会同步一个带pod name的pod框架信息出去
3. volumeManager创建卷
4. 计算sandbox和container的状态来决定是否要创建sandbox以及container
5. 2-4步任意一步失败都会导致该pod信息被投递到workqueue然后等待syncCh 1秒触发来进行重新SYNC
6. sandbox和container的变化都会被PLEG感知，然后状态被记入podCache，并生成事件由PLEGCh触发处理pod的状态的sync，从而回到第二步syncPod
7. 当pod创建完毕后，PLEG感知到container和sandbox暂时不会发生状态变化，则不会生成事件，剩下的则是syncPod的结果无论成功失败都会enqueue到workqueue操作，等待resync pod
8. 值得注意的是，statusManager内维护的status信息是带版本的，一旦有相应的cache并且cache内的status和即将同步给apiserver的status不一致，则会向apiserver同步status并且version+1
