我不知道删除PVC后如何访问数据,以及为什么删除PVC后PV不会消失。
我正在采取的步骤:
1.在GCE中手动创建磁盘:
gcloud compute disks create --size 5Gi disk-for-rabbitmq --zone europe-west1-b
字符串
1.运行:
kubectl apply -f /tmp/pv-and-pvc.yaml
型
使用以下配置:
# /tmp/pv-and-pvc.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-for-rabbitmq
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 5Gi
gcePersistentDisk:
fsType: ext4
pdName: disk-for-rabbitmq
persistentVolumeReclaimPolicy: Delete
storageClassName: standard
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-for-rabbitmq
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: standard
volumeName: pv-for-rabbitmq
型
1.手动删除PVC(在高级别:我在这里模拟了一个灾难性的场景,比如helm
版本的意外删除或错误配置):
kubectl delete pvc pvc-for-rabbitmq
型
在这一点上,我看到以下内容:
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-for-rabbitmq 5Gi RWO Delete Released staging/pvc-for-rabbitmq standard 8m
$
型
一个侧面的问题,只是提高我的理解:**为什么PV仍然存在,即使它的回收策略设置为Delete
?**这不就是文档中所说的Delete
回收策略吗?
现在,如果我尝试重新创建PVC以重新获得对PV中数据的访问:
$ kubectl apply -f /tmp/pv-and-pvc.yaml
persistentvolume "pv-for-rabbitmq" configured
persistentvolumeclaim "pvc-for-rabbitmq" created
$
型
我仍然得到这个为pv
s,例如。PV卡在Released
状态:
$
kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-for-rabbitmq 5Gi RWO Delete Released staging/pvc-for-rabbitmq standard 15m
$
型
...我得到pvc
s:
$
kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-for-rabbitmq Pending pv-for-rabbitmq 0 standard 1m
$
型
看起来我的PV卡在Released
状态,PVC无法访问不在Available
状态的PV。
那么,为什么同样的PV和PVC不能再做朋友呢?如何创建PVC以重新访问现有PV中的数据?
7条答案
按热度按时间drnojrws1#
字符串
这对我很有效。
xtupzzrd2#
关于PV的官方文件有这样的答案:
Retain
回收策略允许手动回收资源。删除PersistentVolumeClaim
时,PersistentVolume
仍然存在,并且卷被视为“已释放”。但另一件索赔尚未获得,因为前一索赔人的数据仍在该卷中。管理员可以通过以下步骤手动回收卷。1.删除
PersistentVolume
。删除PV后,外部基础架构中的关联存储资产(例如AWS EBS、GCE PD、Azure Disk或Cinder卷)仍然存在。1.手动[复制/备份和/或]清理关联存储资产上的数据。
1.手动删除关联的存储资产,或者,如果要重用相同的存储资产,请使用存储资产定义创建一个新的
PersistentVolume
。fhg3lkii3#
Pod消耗节点资源,PVC消耗PV资源的短语可能有助于充分理解PV和PVC之间的理论和友谊。
我已经尝试使用提供的YAML文件完整再现所记录的行为,但失败了,它返回了预期的结果。因此,在提供任何进一步的细节之前,这里是我的复制品的一个演练。
**步骤1:**在欧洲西部1区创建PD
字符串
**步骤2:**使用项目YAML文件创建PV和PVC
型
**第三步:**列出所有可用PVC
型
**第四步:**列出所有可用PV
型
**第五步:**删除PVC并验证结果
型
未找到资源。
型
未找到资源。
型
服务器没有资源类型“pvc-for-rabbitmq”
根据你的问题
你是绝对正确的,根据文档,当用户完成了他们的卷,他们可以从允许回收资源的API中删除PVC对象。* *PersistentVolume**的回收策略告诉集群在释放卷声明后如何处理该卷。在YAML中,它被设置为:
型
这意味着它应该立即被删除。目前,卷可以是保留、回收和 * 删除**。
**为什么没有删除?**我唯一能想到的,可能是PV以某种方式仍然被要求,这可能是由于PVC没有成功删除,因为它的容量显示“0”,要解决这个问题,您需要删除POD。或者,您可以使用
$ kubectl describe pvc
命令来查看PVC为什么仍然处于挂起状态。对于这个问题,如何制作PVC以重新访问现有PV中的数据?
这是不可能的,因为回收策略的状态,即
Reclaim Policy: Delete
要实现这一点,您需要按照文档使用Retain选项要验证删除PVC并保留磁盘的理论,请执行以下操作:
然后验证磁盘是否被保留。
fslejnso4#
类似于@Bharat查布拉的回答,但它会将 all Released PersistentVolumes的状态修改为Available:
字符串
vmdwslir5#
我写了一个简单的自动PV释放器控制器,它可以找到并为新的PVC再次生成
Released
PVAvailable
,在这里查看https://github.com/plumber-cd/kubernetes-dynamic-reclaimable-pvc-controllers。但请确保您阅读免责声明,并确保这正是您想要的。Kubernetes不会自动执行此操作是有原因的-工作负载不应该访问其他工作负载的数据。当它们这样做时-惯用的Kubernetes方法是StatefulSets,因此Kubernetes保证只有相同工作负载的副本可以声明旧数据。我的releaser在某些情况下当然可能是有用的,比如CI/CD构建缓存(它是为之创建的)--但通常PVC意味着“给予我一个干净的现成存储,我可以在上面保存一些数据”,所以至少--让它成为一个单独的StorageClass。
inn6fuwd6#
其他答案中的补丁只有在删除部署后才对我有效。
之后,终结资源被释放。
删除列出的所有资源:
字符串
对于您在此处看到的每个资源,使用
kubectl -n YOURNAMESPACE <resource> <id>
或(如果您从上面的输出中复制粘贴)kubectl -n YOURNAMESPACE <resource>/<id>
。你也可以一次做
kubectl -n YOURNAMESPACE <resource>/<id1> <resource>/<id2> <resource2>/<id3> <resource2>/<id4> <resource3>/<id5>
等。可能您试图删除资源,但由于
deployment
或replicaset
资源,它们正在重新创建,从而阻止名称空间释放依赖的资源并被清理。lnxxn5zx7#
巴拉特的回答对我也很有效。
如果您的PV显示为“已发布”,并且您已经通过helm uninstall或其他方法删除了该PV,那么您不能再次使用此PV,除非您删除索赔参考:
字符串
请记住,您不能这样做,除非当PV被绑定时,您必须首先删除PVC,以便PV显示“Released”,然后您可以运行此命令。PV的状态应显示为“可用”,并可重复使用。