我很难理解VolumeClaimTemplates相对于预定义PV/PVC和标准模板的优点和缺点。
我们有一个StatefulSet A，它包含几百个pod，每个pod都需要装载少量静态数据库-DB 1-DB 4。我们目前没有显式地保存任何状态，而是使用StatefulSet为大量并行真实的时间计算提供确定性和排序。每个副本执行一部分计算，这些计算稍后将被排序和进一步处理。
我们目前使用NFS卷挂载到数据库中。我对Kubernetes文档中描述的NFS卷的理解本质上或多或少是持久性的。如果我的理解是正确的，那么除了从各个helm模板中抽象出NFS配置信息之外，使用PV/PVC与静态预填充数据的普通卷挂载相比，真的有什么好处吗？当我们比较VolumeClaimTemplates与预定义PV/PVC的用例时，情况又如何呢？
我对VolumeClaimTemplates的理解是，它的主要好处是为每个副本提供了自己的PV/PVC供使用（并且可能在缩放/重新安装 Helm 之间重用）。我不一定理解的是为什么这是一个好处？特别是NFS，它们都不使用相同的底层存储吗？
此外，站立这么多PV/PVC是否有任何潜在的负面影响？是否对节点级资源或站立时间有任何潜在影响？我觉得我了解大部分基础知识，但缺少一些关键细节，这些细节将使所有点击。
我曾经尝试过切换到手动定义的PV/PVC-同样是使用NFS -以抽象出卷的NFS配置信息（由集群管理员接管）。也就是说，我为每个静态数据库创建了一个PV和PVC，并修改了StatefulSet以使用PVC。
实际上，这意味着当我安装图表时，数百个pod正在启动，所有人都试图使用声明。因此，我偶尔会看到一些pod无法挂载卷的问题。
不幸的是，由于我们周围的现有基础设施和应用程序的需求，我们目前无法一次性安装图表，根据需要缩放并保持不变。相反，每次用户想要做一些处理时，他们都会设置特定的参数并启动它。
这意味着在实践中，我们一次会有几个单独的Helm版本。当一个运行完成时，该版本将被重新启动。当需要一个新的版本时，它将被创建并预计在合理的时间内运行。
1条答案
按热度按时间daolsyd01#
对于您正在使用的设置，特别是在Helm上下文中，我可能会将内联
volumes:放在Pod规范中。PersistentVolume（Claim）机制在集群本身分配存储的情况下工作得更好。
1.您的Kubernetes YAML使用
volumeClaimTemplates声明了一个StatefulSet。1.* 集群 * 为每个副本创建一个PersistentVolumeClaim;您不需要自己创建PVC。
1.* 集群 * 为每个PVC创建一个PersistentVolume;您自己不创建PV。
1.* 集群 * 分配存储（在AWS/EKS上，例如，EBS卷）;您不自己分配存储。
这也会在另一个方向上运行。如果您删除PVC，集群将删除PV和底层存储。
但是，在您的例子中，您不希望集群管理存储;您有一个现有的集群外NFS存储，您想使用。我不认为设置PersistentVolume（Claim）手动指向这个存储有什么特别的好处。这是双重正确的，因为PersistentVolume是一个集群全局对象，所以您必须小心命名它，这样在多个安装之间就不会发生冲突。
更具体地说，在Helm上下文中，您可以使用一个配置选项来选择是使用特定的NFS存储还是使用
volumeClaimTemplates。对于开发人员设置，集群内存储可能有意义，但对于（预）生产，集群外存储可能有意义。在一个只有几百个PV（C）的规模上，我不认为这会给集群带来压力。在我的日常工作中，我们有一个共享的开发集群，每个开发人员命名空间可以轻松地创建十几个PV（C），这对我们来说不是问题。