Kubernetes StatefulSet相关疑问：持久化卷与本地存储访问问题

咱们逐个拆解你的问题：

问题1：StatefulSet的Pod在同一节点重启后，能否访问原来的持久化卷？ #

当然可以！StatefulSet的核心特性之一就是给每个Pod分配稳定的唯一身份，对应的PersistentVolumeClaim（PVC）也是和Pod身份绑定的（比如名为web-0的Pod，会关联web-0-data这类命名的PVC）。当Pod在同一节点重启时：

• 如果用的是远程持久化卷（比如EBS、NFS、Ceph）：kubelet会重新挂载和该PVC绑定的PersistentVolume（PV），数据完全保留，直接就能访问；
• 如果用的是本地存储卷：只要节点上的存储介质（比如本地磁盘、SSD）没有损坏，重启后的Pod仍然会挂载同一个本地PV，原来的数据都在，可以正常访问。

问题2：关于分布式数据库与本地存储的疑问 #

子问题1：数据库进程崩溃，是否会在同一节点重启？ #

答案是通常会，这取决于几个因素：

• 首先，Pod的重启策略默认是Always，当数据库进程崩溃时，节点上的kubelet会自动重启该Pod，而且优先在当前节点重启——除非这个节点本身出现故障（比如宕机、资源耗尽）。
• 如果你的StatefulSet搭配了本地存储PV，因为本地PV是和特定节点绑定的，Kubernetes调度器会强制把Pod调度回原来的节点（其他节点没有对应的本地PV），所以只要节点正常，进程崩溃后一定会在原节点重启。

子问题2：重启后能否访问崩溃前使用的本地存储？ #

完全可以！本地存储PV是节点上的物理存储资源，Pod重启后会重新挂载同一个PV，崩溃前写入的数据都保存在这个存储介质上，重启后直接就能读取和使用。这也是分布式数据库偏好本地存储的原因之一——低延迟，数据直接存在本地节点，重启后无需远程拉取。

子问题3：旧文章说StatefulSet Beta阶段不鼓励用本地存储，现在情况如何？ #

你提到的是早期Kubernetes的情况啦！在StatefulSet还处于Beta阶段时，本地存储特性（LocalPersistentVolume）也还不成熟：比如没有动态供给能力、节点故障后无法自动调度替换、缺乏完善的存储管理工具，当时确实不推荐用于生产环境。

但现在不一样了：LocalPersistentVolume在Kubernetes 1.14版本就已经GA（稳定版），StatefulSet也早就成为稳定特性。现在Kubernetes已经支持本地存储的动态供给、节点亲和调度、存储拓扑感知等功能，用StatefulSet搭配本地存储跑分布式数据库（比如ETCD、MongoDB分片、TiDB）已经是非常常见的生产级部署方案，完全可以放心使用。

内容的提问来源于stack exchange，提问作者Ashish Negi