108

我通过调用创建了以下持久卷

kubectl create -f nameOfTheFileContainingTheFollowingContent.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-monitoring-static-content
spec:
  capacity:
    storage: 100Mi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/some/path"

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-monitoring-static-content-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ""
  resources:
    requests:
      storage: 100Mi

在此之后,我尝试删除 pvc。但是这个命令卡住了。打电话时kubectl describe pvc pv-monitoring-static-content-claim我得到以下结果

Name:          pv-monitoring-static-content-claim
Namespace:     default
StorageClass:
Status:        Terminating (lasts 5m)
Volume:        pv-monitoring-static-content
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed=yes
               pv.kubernetes.io/bound-by-controller=yes
Finalizers:    [foregroundDeletion]
Capacity:      100Mi
Access Modes:  RWO
Events:        <none>

而对于kubectl describe pv pv-monitoring-static-content

Name:            pv-monitoring-static-content
Labels:          <none>
Annotations:     pv.kubernetes.io/bound-by-controller=yes
Finalizers:      [kubernetes.io/pv-protection foregroundDeletion]
StorageClass:
Status:          Terminating (lasts 16m)
Claim:           default/pv-monitoring-static-content-claim
Reclaim Policy:  Retain
Access Modes:    RWO
Capacity:        100Mi
Node Affinity:   <none>
Message:
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /some/path
    HostPathType:
Events:            <none>

没有运行使用持久卷的 pod。谁能给我一个提示,为什么 pvc 和 pv 没有被删除?

4

12 回答 12

222

当持久卷受到保护时会发生这种情况。您应该能够交叉验证这一点:

命令:

kubectl describe pvc PVC_NAME | grep Finalizers

输出:

Finalizers: [kubernetes.io/pvc-protection]

您可以通过使用以下方法将终结器设置为 null 来解决此问题kubectl patch

kubectl patch pvc PVC_NAME -p '{"metadata":{"finalizers": []}}' --type=merge

参考;使用中的存储对象保护

于 2019-05-17T08:55:48.653 回答
24

我不确定为什么会发生这种情况,但是在通过 kubernetes 仪表板删除 pv 和 pvc 的终结器后,两者都被删除了。重复我在问题中描述的步骤后,再次发生这种情况。似乎是一个错误。

于 2018-07-17T18:19:01.483 回答
24

你可以摆脱编辑你的 pvc !去除 pvc 保护。

  1. kubectl 编辑 pvc YOUR_PVC -n NAME_SPACE
  2. 手动编辑并将 # 放在此行之前 在此处输入图像描述
  3. 所有 pv 和 pvc 将被删除
于 2019-06-05T08:17:44.563 回答
15

PV 受到保护。在删除 PVC 之前先删除 PV。此外,删除任何声明任何引用 PVC 的 pod/部署。有关更多信息,请查看使用中的存储对象保护

于 2018-07-16T11:38:31.390 回答
11

对我来说 pv 处于保留状态,因此执行上述步骤不起作用。

首先我们需要改变策略状态如下:

kubectl patch pv PV_NAME -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'

然后删除 pvc 如下。

kubectl get pvc

kubectl delete pvc PVC_NAME

最后,删除 pv 与

kubectl delete pv PV_NAME
于 2020-05-19T16:11:28.270 回答
6

几个小时前刚遇到这个问题。

我删除了使用此引用的部署,并且 PV/PVC 会自动终止。

于 2018-10-18T04:07:02.027 回答
5

如果 PV 仍然存在,可能是因为它的 ReclaimPolicy 设置为 Retain,在这种情况下,即使 PVC 消失,它也不会被删除。从文档:

PersistentVolume 可以有多种回收策略,包括“保留”、“回收”和“删除”。对于动态配置的 PersistentVolume,默认回收策略是“删除”。这意味着当用户删除相应的 PersistentVolumeClaim 时,会自动删除动态配置的卷。如果卷包含宝贵的数据,则此自动行为可能不合适。在这种情况下,使用“保留”策略更为合适。使用“保留”策略,如果用户删除 PersistentVolumeClaim,则不会删除相应的 PersistentVolume。相反,它被移至已发布阶段,其中所有数据都可以手动恢复

于 2018-11-14T17:14:48.647 回答
5

就我而言,只要我删除与pvand关联的 pod pvcpvandpvc终止状态就消失了

于 2019-03-09T06:39:08.080 回答
0

在我的情况下,pvc 没有被删除,因为缺少命名空间(我在删除所有资源/pvc 之前删除了命名空间)解决方案:创建与以前相同的名称的命名空间,然后我能够删除finalizers最后的 pvc

于 2019-11-14T11:14:51.407 回答
0

如果您已经删除 PV 并尝试删除 PVC

检查此命令是否附加了卷

kubectl 获取卷附件

删除 PVC :-

首先,您必须使用此命令逐个删除 pvc pne

kubectl 删除 pvc <pvc_name> --grace-period=0 --force

或者您可以使用删除所有 PVC

kubectl 删除 pvc --all

现在您可以通过使用看到 PVC 的状态为终止

kubectl 获取 pvc

然后你必须使用这个删除

kubectl patch pvc {PVC_NAME} -p '{"metadata":{"finalizers":null}}'

于 2020-12-17T11:16:08.980 回答
0
kubectl get pvc pvc_name -o yaml > pvcfile.yaml

然后打开 pvcfile.yaml 并删除 finalizers 行,保存并应用:

kubectl apply -f pvcfile.yaml 
于 2021-06-10T16:02:15.803 回答
0

除了关于终结器的其他答案......

只有在删除部署后才能释放资源。之后,终止资源被释放。


删除以下列出的所有资源:

kubectl get all -n YOURNAMESPACE

对于您在此处看到的每个资源,请使用kubectl delete -n YOURNAMESPACE <resource> <id>or(如果您从上述输出中复制粘贴) 。kubectl delete -n YOURNAMESPACE <resource>/<id>

您也可以一次完成

kubectl delete -n YOURNAMESPACE <resource>/<id1>  <resource>/<id2>  <resource2>/<id3>  <resource2>/<id4>  <resource3>/<id5>

可能您尝试删除资源,但由于deploymentorreplicaset资源而重新创建它们,从而阻止命名空间释放依赖资源并被清理。

于 2022-02-15T17:47:46.140 回答