在Kubernetes部署中为每个pod附加新的azure磁盘卷

我有一个Kubernetes部署应用程序，其中包含3个副本，每个副本需要7GB的存储空间，我希望能够在部署中创建的每个pod/副本中附加一个新的空存储空间

基本上，我有以下限制：

• 我必须使用部署，而不是状态集
• 每次一个pod死亡，一个新的pod启动时，它不应该有一个状态，它将有一个新的空azureDisk连接到它
• 吊舱不共享存储空间，每个吊舱都有自己的7GB存储空间
• POD需要使用azureDisk，因为我需要7GB的随需应变存储，这意味着在扩展部署副本时动态创建azureStorage

当使用azureDisk时，我需要将其与访问模式类型ReadWriteOnce（如中所述）一起使用，它将只将1个pod连接到此磁盘，这是找到的，但是，这仅在我有1个pod时有效，如果我有多个pod，我不能使用相同的声明。。。是否有任何方法可以像第一个声明中那样动态请求更多存储

注1：我知道有volumeClaimTemplates，但它只与Statefulset相关

---

注2：我不在乎pod是否重新启动100次，而这又会产生100个PV，只使用1个PV，这很好。

我不知道为什么需要使用StatefolSet，但我看到的唯一方法是为应用程序创建自己的PV。操作员会有一个控制器来管理您的pod，与a类似，但对于实例化的每个新pod，都会创建一个新的PVC

最好弄清楚如何在StatefulSet中运行应用程序并使用

✌️

主要问题是-为什么？如果我有一个没有状态的应用程序，我仍然需要为每个pod提供一个大容量

看看这个解释，您应该把重点放在状态完整的应用程序上。在我看来，您似乎正在强制使用部署，而不是statefulset

在您的示例中，可能需要支持不同功能的pv

您遇到的主要问题是，使用支持模式的pvReadWriteOnce时，单个节点只能同时绑定一个pv。因此，由于卷装载失败，不同节点中的吊舱将无法启动。您只能在ReadOnlyMany/ReadWriteMany场景中使用此方法

请参考具有不同访问模式功能的其他提供商，如：、Glusterfs、NFS

---

您能否澄清一下，为什么您需要使用

部署
而不是
状态集
，它的设计目的就是为了解决这些类型的用例？我必须问，为什么部署不能使用像7G这样的大容量，从云提供商处按需获取，并在pod死亡后永久删除？为什么它需要statefulset？我不能有一个没有状态的应用程序，但仍然需要一个大的卷吗？甚至没有人需要这样的场景？无论如何，您的解决方案可能会起作用，谢谢。如果您选择默认的
回收策略：Delete
，则会起作用。然而，pvc得到了重用。这里的拦截器是，您只能在部署清单中指定固定的PVC名称，并且所有副本都将使用相同的PVC名称，因此您有限制。它们实际上意味着更多的无状态工作负载，其中您的状态是外部的，如db。您不能使用AzureFiles，因为它用于文件共享，并且您不想在pod之间共享这些文件，唯一的选项是使用azureDisk，但它只支持ReadWriteOnce，并且只属于1个pod。如果你想要多个azureDisk，你必须使用带VolumeClaim模板的有状态集合，它将为每个pod生成一个卷。但我希望PV的生命周期与pod的生命周期一样。为什么这么奇怪？顺便说一句，我在Azure上，显然，我不会仅仅因为这个问题而转移到其他云提供商。有关进一步的参考，请关注这个问题：