我正在尝试更新Kubernetes集群中的MinIO部署，在升级Helm chart或镜像版本之前，我在访问上传到MinIO部署的任何数据时遇到了一些问题。这特别是关于MinIO，但这个问题（和潜在的解决方案）可以应用于任何需要存储和PV/PVC的应用程序部署。
因此，我想将我的MinIO部署映像+ Helm图表升级到下一个，但每当我这样做时，我都会丢失所有数据，创建的任何存储桶，上传到存储桶的任何文件，任何访问策略，几乎所有内容。我的存储连接了AWS EFS。
我发现了第一个问题，即我们正在使用storageClasses并执行PV和PVC的动态供应，因此当部署发生更改或更新时，（不更改Helm chart值，仅专门更改Helm chart版本或MinIO映像版本）创建了新的接入点，同时也创建了新的PV和PVC，因此，在这些新对象中没有任何现有数据。所以我做了一些谷歌搜索，发现我可以静态提供EFS接入点，并手动创建PV和PVC。然后我的PV可以使用spec.volumeHandle定义引用PV中的接入点ID，如下所示：
apiVersion: v1
kind: PersistentVolume
metadata:
name: minio
spec:
capacity:
storage: 50Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
csi:
driver: efs.csi.aws.com
volumeHandle: fs-<numbers>::fsap-<numbers>字符串
除此之外，我还需要在PVC中添加spec.volumeName定义：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: minio
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 50Gi
volumeName: minio型
通过这种配置，看起来我可以使用相同的PV和PVC，并且没有配置新卷。“太好了！”我想，所以我测试了Helm chart版本的升级，但所有数据仍然消失，即使在升级的部署中使用相同的PV和PVC。
我真的不知道我现在做错了什么，因为肯定没有新的卷被配置，我肯定使用现有的卷。
如何在不丢失数据的情况下升级我的MinIO部署？我以为这和使用相同的PV一样简单，但我肯定错过了什么。
1条答案
按热度按时间mkh04yzy1#
您几乎不应该手动创建PersistentClaims，通常也不应该创建PersistentVolumeClaims。
如果您的应用程序使用StatefulSet，其中一部分是
volumeClaimTemplates的列表。这指示集群为每个副本创建PersistentVolumeClaim，然后集群也会自动创建PersistentVolume并分配存储。字符串
StatefulSet在这里很有用还有两个原因。首先，删除StatefulSet通常不会删除相应的PersistentVolumeClaim，因此即使在升级时，数据卷也会保留在集群中第二，StatefulSet创建的PersistentVolumeClaim的名称是可预测的，因此您应该看到名为
minio-ssname-0的内容，其中ssname是StatefulSet名称;这意味着，如果StatefulSet被删除并重新创建，它可以找到现有的PVC。在AWS/EKS上下文中，集群通常会为每个PersistentVolumeClaim配置至少具有指定最小大小的EBS卷。您不需要手动创建EFS卷或知道任何创建对象的AWS ID。
您的问题主要集中在PersistentVolume（声明）的机制上，但您的高级症状是在任何更新时都会丢失数据。还需要验证您是否将卷挂载在正确的容器路径上。上面的示例使用了bitnami/minio映像及其记录的容器路径。如果容器路径错误，您将得到您所描述的症状：事情显然是工作的，但数据存储在容器临时文件系统中，所以只要任何东西删除Pod（如例行升级），数据就会消失。