我有一个包含三个节点的 Kubernetes 集群。我需要将 mysql 服务器部署到集群，并且我需要该 mysql 的持久性。因此，当我重新部署或重新启动我的 pod 时，它不会擦除数据。
但是如果我使用一个使用 azure-disk 的 storageClass，它只会被挂载到主机上。
metadata:
name: mysql-storage
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "managed-premium"
resources:
requests:
storage: 5Gi
因此，如果我删除或重新部署 pod，它可能会在未安装磁盘的另一台主机上启动，然后我的数据就消失了。
我尝试将 accessModes 更改为 ReadWriteMany，但在声明卷时失败。说它只支持ReadWriteOnce。
【问题讨论】：
您应该使用 StatefulSet 和 PersistentVolumeClaims (PVC)。
以下指南提供了一个很好的示例，说明如何完全按照您的意愿行事。
kubernetes.io: Run a Replicated Stateful Application
在指南中，需要注意的几点：
StatefulSet 保证这些 Pod 的顺序和唯一性。并且定义包含一个 volumeClaimTemplates
volumeClaimTemplates 将确保每个 pod 都有一个 PersistentVolumeClaims，他们可以在其中写入数据。
PersistentVolumeClaims 保留存储，然后附加\安装到 POD
另外一个细节，如果你想保留数据和完整性，你不应该删除资源，你应该升级。
【讨论】：
StatefulSet Pods have a unique identity that is comprised of an ordinal, a stable network identity, and stable storage. The identity sticks to the Pod, regardless of which node it’s (re)scheduled on. 和存储When a Pod is (re)scheduled onto a node, its volumeMounts mount the PersistentVolumes associated with its PersistentVolume Claims。鉴于此，无论 POD 移动到哪里，PV 和 PVC 都应该附加到 POD，问题是绑定通常很慢，因此如果 POD 经常移动，它可能不太适合。
你无法真正解决这个问题。这个问题有几种解决方法，比如你可以在托管磁盘上创建一个软件存储系统并使用它来存储数据，你可以使用 azure 文件持久存储，它可以从任何 pod（以及许多 pod）挂载。
托管磁盘只能挂载到一个节点（但我认为节点上的所有pod都可以访问这个磁盘），所以ReadWriteMany没有多大意义。你可以使用StatefulSets 来定义你的mysql，它总是会挂载到同一个节点，但我认为你真的不需要它，PVC 应该重新挂载到托管你的 pod 的节点，唯一的缺点是它需要某个地方将托管磁盘重新附加到另一个节点需要 1 分钟。
【讨论】：