这篇文章会写得比较泛。
要知道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并且version1
转:https://www.cnblogs.com/diagnose/p/9724376.html