kubernetes 如何处理已发布的持久卷?

rekjcdws  于 2023-08-03  发布在  Kubernetes
关注(0)|答案(7)|浏览(86)

我不知道删除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中的数据?

drnojrws

drnojrws1#

kubectl patch pv pv-for-rabbitmq -p '{"spec":{"claimRef": null}}'

字符串
这对我很有效。

xtupzzrd

xtupzzrd2#

关于PV的官方文件有这样的答案:
Retain回收策略允许手动回收资源。删除PersistentVolumeClaim时,PersistentVolume仍然存在,并且卷被视为“已释放”。但另一件索赔尚未获得,因为前一索赔人的数据仍在该卷中。管理员可以通过以下步骤手动回收卷。
1.删除PersistentVolume。删除PV后,外部基础架构中的关联存储资产(例如AWS EBS、GCE PD、Azure Disk或Cinder卷)仍然存在。
1.手动[复制/备份和/或]清理关联存储资产上的数据。
1.手动删除关联的存储资产,或者,如果要重用相同的存储资产,请使用存储资产定义创建一个新的PersistentVolume

fhg3lkii

fhg3lkii3#

Pod消耗节点资源,PVC消耗PV资源的短语可能有助于充分理解PV和PVC之间的理论和友谊。
我已经尝试使用提供的YAML文件完整再现所记录的行为,但失败了,它返回了预期的结果。因此,在提供任何进一步的细节之前,这里是我的复制品的一个演练。

**步骤1:**在欧洲西部1区创建PD

sunny@dev-lab:~$ gcloud compute disks create --size 5Gi disk-for-rabbitmq --zone europe-west1-b

WARNING: You have selected a disk size of under [200GB]. This may result in poor I/O 
performance. For more information, see: 

NAME               ZONE            SIZE_GB  TYPE         STATUS
disk-for-rabbitmq  europe-west1-b  5        pd-standard  READY

字符串

**步骤2:**使用项目YAML文件创建PV和PVC

sunny@dev-lab:~$  kubectl apply -f pv-and-pvc.yaml

persistentvolume "pv-for-rabbitmq" created
persistentvolumeclaim "pvc-for-rabbitmq" created

**第三步:**列出所有可用PVC

sunny@dev-lab:~$ kubectl get pvc
NAME               STATUS    VOLUME            CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-for-rabbitmq   Bound     pv-for-rabbitmq   5Gi        RWO            standard       16s

**第四步:**列出所有可用PV

sunny@dev-lab:~$ kubectl get pv
NAME              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                      STORAGECLASS   REASON    AGE
pv-for-rabbitmq   5Gi        RWO            Delete           Bound     default/pvc-for-rabbitmq   standard                 28s

**第五步:**删除PVC并验证结果

sunny@dev-lab:~$  kubectl delete pvc pvc-for-rabbitmq
persistentvolumeclaim "pvc-for-rabbitmq" deleted

sunny@dev-lab:~$  kubectl get pv


未找到资源。

sunny@dev-lab:~$  kubectl get pvc


未找到资源。

sunny@dev-lab:~$  kubectl describe pvc-for-rabbitmq


服务器没有资源类型“pvc-for-rabbitmq”

根据你的问题

  • 一个附加问题,只是提高我的理解:为什么PV仍然存在,即使它有一个**回收策略设置为删除?*这不正是文档中针对删除回收策略所说的吗?

你是绝对正确的,根据文档,当用户完成了他们的卷,他们可以从允许回收资源的API中删除PVC对象。* *PersistentVolume**的回收策略告诉集群在释放卷声明后如何处理该卷。在YAML中,它被设置为:

Reclaim Policy:  Delete


这意味着它应该立即被删除。目前,卷可以是保留回收和 * 删除**。

**为什么没有删除?**我唯一能想到的,可能是PV以某种方式仍然被要求,这可能是由于PVC没有成功删除,因为它的容量显示“0”,要解决这个问题,您需要删除POD。或者,您可以使用$ kubectl describe pvc命令来查看PVC为什么仍然处于挂起状态。

对于这个问题,如何制作PVC以重新访问现有PV中的数据?
这是不可能的,因为回收策略的状态,即Reclaim Policy: Delete要实现这一点,您需要按照文档使用Retain选项

要验证删除PVC并保留磁盘的理论,请执行以下操作:

  • 将回收策略更改为“保留”
  • 删除PVC
  • 删除PV

然后验证磁盘是否被保留。

fslejnso

fslejnso4#

类似于@Bharat查布拉的回答,但它会将 all Released PersistentVolumes的状态修改为Available:

kubectl get pv | tail -n+2 | awk '$5 == "Released" {print $1}' | xargs -I{} kubectl patch pv {} --type='merge' -p '{"spec":{"claimRef": null}}

字符串

vmdwslir

vmdwslir5#

我写了一个简单的自动PV释放器控制器,它可以找到并为新的PVC再次生成Released PV Available,在这里查看https://github.com/plumber-cd/kubernetes-dynamic-reclaimable-pvc-controllers
但请确保您阅读免责声明,并确保这正是您想要的。Kubernetes不会自动执行此操作是有原因的-工作负载不应该访问其他工作负载的数据。当它们这样做时-惯用的Kubernetes方法是StatefulSets,因此Kubernetes保证只有相同工作负载的副本可以声明旧数据。我的releaser在某些情况下当然可能是有用的,比如CI/CD构建缓存(它是为之创建的)--但通常PVC意味着“给予我一个干净的现成存储,我可以在上面保存一些数据”,所以至少--让它成为一个单独的StorageClass。

inn6fuwd

inn6fuwd6#

其他答案中的补丁只有在删除部署后才对我有效。
之后,终结资源被释放。
删除列出的所有资源:

kubectl -n YOURNAMESPACE get all

字符串
对于您在此处看到的每个资源,使用kubectl -n YOURNAMESPACE <resource> <id>或(如果您从上面的输出中复制粘贴)kubectl -n YOURNAMESPACE <resource>/<id>
你也可以一次做kubectl -n YOURNAMESPACE <resource>/<id1> <resource>/<id2> <resource2>/<id3> <resource2>/<id4> <resource3>/<id5>等。
可能您试图删除资源,但由于deploymentreplicaset资源,它们正在重新创建,从而阻止名称空间释放依赖的资源并被清理。

lnxxn5zx

lnxxn5zx7#

巴拉特的回答对我也很有效。
如果您的PV显示为“已发布”,并且您已经通过helm uninstall或其他方法删除了该PV,那么您不能再次使用此PV,除非您删除索赔参考:

kubectl patch pv PV_NAME -p '{"spec":{"claimRef": null}}'

字符串
请记住,您不能这样做,除非当PV被绑定时,您必须首先删除PVC,以便PV显示“Released”,然后您可以运行此命令。PV的状态应显示为“可用”,并可重复使用。

相关问题