Kubernetes环境偶尔出现StatefulSet中的Pod被删除，新启动的Pod（还是调度到原有节点）挂载volume失败的问题，如下图，经过一番定位分析，也让我们对于Kubernetes系统复杂程度有了新的认知。
在分析此问题之前，作为相关背景知识，先简单介绍对于Kubernetes存储系统的理解。
存储系统简析
存储也是Kubernetes中比较重要而复杂的系统，功能比较庞大，涉及到不同组件中，不同控制器的协作，如下图。
从三个维度分析：
1、从卷的生命周期来讲，卷被Pod使用或者卷被回收，会依赖顺序严格的几个阶段
卷被Pod使用：
- provision，卷分配成功
- attach，卷挂载在对应worker node
- mount，卷挂载为文件系统并且映射给对应Pod
卷要成功被Pod使用，需要遵循以上顺序。
卷被回收：
- umount，卷已经和对应worker node解除映射，且已经从文件系统umount
- detach，卷已经从worker node卸载
- recycle，卷被回收
卷要成功回收，需要遵循以上顺序。
2、从Kubernetes存储系统来讲，卷生命周期管理的职责，又分散于不同的控制器中
- pv controller，负责创建和回收卷
- attach detach controller，负责挂载和卸载卷
- volume manager，负责mount和umount卷
3、controller模式，每个controller负责特定功能，并且不断进行reconcile（对比期望状态与实际状态），然后进行调整
比如attach detach controller和volume manager中，各自都会有desiredStateOfWorld（缓存期望状态）和actualStateOfWorld（缓存实际状态）缓存，并且由各自的syncLoopFunc不断对比两个缓存的差异，并进行调整，下文中会介绍。
结合以上三个维度，Kubernetes需要保证卷的管理功能分布在不同控制器的前提下保证卷生命周期顺序的正确性。以Pod使用卷为例，看Kubernetes是如何做到这一点？
Pod启动流程
假设scheduler已经完成worker node选择，确定调度的节点，此时启动Pod前，需要先完成卷映射到Pod路径中，结合前面的分析，整个过程如下：
1、卷分配，pvc绑定pv，由pv controller负责完成，结合相关代码1[1]。
此时pvc绑定pv。
2、attach detach controlle，如果pod分配到worker node，并且对应卷已经创建，则将卷挂载到对应worker node，并且给worker node资源增加volume已经挂载对应卷的状态信息，结合相关代码2[2]和代码3[3]。
此时对应node资源状态中增加volume信息。
3、volume manager在worker node中负责将卷挂载到对应路径。
Pod分配到本worker node后，获取Pod需要的volume，通过对比node状态中的volumesAttached，确认volume是否已经attach到node节点，如果attach到node节点则将自身actualStateOfWorld中的volume状态设置成attached，对应代码4[4]、代码5[5]。
如果已经attached成功，则进入到文件系统挂载流程，相关代码6[6]。
- 先挂载到node中全局路径，比如/var/lib/kubelet/plugins/kubernetes.io/csi/pv/pvc-3ecd68c7b7d211e8/globalmount。
- 映射到Pod对应路径，比如/var/lib/kubelet/pods/49a5fede-b811-11e8-844f-fa7378845e00/volumes/kubernetes.io~csi/pvc-3ecd68c7b7d211e8/mount。
- actualStateOfWorld中设置volume为挂载成功状态。
4、pod controller确认卷已经映射成功，启动Pod，此处不详细展开。
Pod被删除的过程
pod controller watch到pod处于被删除状态，执行killPod操作，删除Pod，此处不详细展开。
volume manager获取到Pod被删除的信息，会执行如下几步，相关代码5[5]。
- 将Pod从desiredStateOfWorld的缓存信息中清除。
- actualStateOfWorld中已经挂载的卷和desiredStateOfWorld发现Pod不应该挂载，执行UmountVolume操作，将Pod和卷映射关系解除，并将Pod从actualStateOfWorld的卷信息中剔除。
- 此时如果实际状态中卷没有关联任何Pod，则说明卷需要可以完全与节点分离，则先执行UnmountDevice将卷的globalpath umount掉，等到下次reconcile时执行MarkVolumeAsDetached将卷完全从实际状态中删除掉。
attach detach controller发现挂载到node节点的volume没有被Pod使用，执行detach操作，将卷从node节点detach，此时卷完全处于集群中未被使用的状态，此处不详细展开。
总结为Kubernetes存储系统的特点：
- 不同组件通过资源状态协作，attach detach controller需要PVC绑定PV的状态，volume manager需要node status中volume attached状态。
- 组件通过reconcile方式达到期望状态，并且状态可能需要多次reconcile中完成，如Pod清除掉后，volume最终和node分离。
问题
理解了存储系统的整体过程之后，回到问题，StatefulSet中Pod被删除会发生什么？
首先，对于StatefulSet的了解，Pod被删除，StatefulSet controller应该会很快创建Pod，在我们的场景中，Pod还是调度到先前节点中启动。结合对存储的理解，可能的场景：
场景一：delete Pod，感知顺序为volume manager(umount)->statefulset->scheduler->volume manager(mount)。
- volume manager发现Pod被删除，执行umount
- StatefulSet发现Pod被删除，马上创建Pod
- scheduler发现Pod进行调度
- volume manager发现原有volume需要绑定Pod，执行mount
场景二：delete Pod，感知顺序为volume manager(umount)->volume manager(unmountDevice)->volume manager(MarkVolumeAsDelete)->attach detach controller(Detach)->statefulset->scheduler->attach detach controller(Attach)->volume manager。
- volume manager发现Pod被删除，执行umount/unmountDevice/MarkVolumeAsDelete（通过几次reconcile）
- attach detach controller发现volume在node节点未被使用，执行detach
- scheduler发现Pod进行调度
- attach detach controller发现volume需要attach，执行attach
- volume manager挂载
场景三：delete Pod，感知顺序为statefulset->volume manager(umount/deviceUmount)->scheduler->volume manager(mount)。
- StatefulSet发现Pod被删除，马上创建Pod
- volume manager发现Pod被删除，执行umount/deviceUmount（通过几次reconcile），注意此时devicePath和deviceMountPath都为空
- scheduler发现Pod进行调度
- volume manager发现原有volume需要绑定Pod，执行mount而此时devicePath和deviceMountPath都为空，问题出现
再结合问题出现日志分析：
WaitForAttach有两个阶段：
- Sep 14 19:29:14以及之前DevicePath非空
- Sep 14 19:29:45以及之后DevicePath为空
那么在这两个时间点之间发生了什么，怀疑这个时间点发生的问题造成卷无法挂载。
通过日志发现Sep 14 19:29:14到Sep 14 19:29:45有一段日志信息比较关键，分析如下：
在步骤4中，有设置相关函数的：
其中比较关键的函数SetVolumeGloballyMounted：
总结
Kubernetes之所以在当前成为容器编排领域的事实标准，原因很多，但是对我们来讲基于声明式API的编程范式是我们依赖Kubernetes的重要原因，当然在其解决的问题规模下复杂程度也不言而喻，总之，一句话，没有银弹。