取消或撤消删除kubernetes群集中的永久卷

意外地尝试删除集群中的所有PV，但谢天谢地，它们仍然有绑定到它们的PVC，因此所有PV都处于“终止”状态

如何使PV脱离“终止”状态并恢复到与pvc“结合”并完全工作的健康状态

这里的关键是，我不想丢失任何数据，我想确保这些卷能够正常工作，并且在索赔消失时不会有被终止的风险

以下是PV上kubectl描述的一些细节

$ kubectl describe pv persistent-vol-1
Finalizers:      [kubernetes.io/pv-protection foregroundDeletion]
Status:          Terminating (lasts 1h)
Claim:           ns/application
Reclaim Policy:  Delete

这是对索赔的描述

$ kubectl describe pvc application
Name:          application
Namespace:     ns
StorageClass:  standard
Status:        Bound
Volume:        persistent-vol-1

---

不幸的是，在这种情况下，您无法保存PV和数据。 您可以使用

回收策略：Retain

-重新创建PV-这将防止将来的数据丢失。 您可以阅读有关回收策略和回收的更多信息

如果删除PersistentVolumeClaim（PVC），会发生什么？如果卷 已动态设置，则默认回收策略设置为 “删除”。这意味着，默认情况下，删除PVC时 基础光伏和存储资产也将被删除。如果你想 保留存储在卷上的数据，然后必须更改回收 配置PV后，从“删除”到“保留”的策略

---

事实上，可以将

持久卷

中的数据保存为

状态：终止

和

保留策略

设置为默认值（删除）。我们已经在GKE上这样做了，不确定AWS或Azure，但我想它们是相似的

我们有同样的问题，我会在这里发布我们的解决方案，以防其他人有这样的问题

您的

PersistenVolumes

将不会被终止，直到有一个pod、部署或更具体的-a

persistenvolumeClaim

使用它

我们采取的补救措施是：

一旦您遇到这种情况（如OP），您要做的第一件事就是创建

持久卷的快照

在GKE控制台中，转到
Compute Engine->Disks
，在那里找到您的卷（使用
kubectl get pv | grep pvc name
），并创建卷的快照

使用快照创建磁盘：
gcloud compute disks创建磁盘名称--size=10--源快照=快照名称--type=pd-standard--zone=your zone

此时，停止使用卷的服务，并删除卷和卷声明。

使用磁盘中的数据手动重新创建卷：

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: name-of-pv
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 10Gi
  gcePersistentDisk:
    fsType: ext4
    pdName: name-of-disk
  persistentVolumeReclaimPolicy: Retain

现在只需更新您的卷声明以针对特定卷，yaml文件的最后一行：

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: my-namespace
  labels:
    app: my-app
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  volumeName: name-of-pv

如果您不知道自己在做什么，请不要尝试此操作

还有另一种相当骇客的方法来取消删除PV。直接编辑etcd中的对象。请注意，只有在您控制etcd的情况下，以下步骤才起作用-在某些云提供商或托管产品上可能不是这样。还要注意的是，你很容易把事情搞砸；由于etcd中的对象从未打算直接编辑，因此请谨慎处理

我们的PVs有一个
delete
策略，我意外地在K8S1.11上运行了一个命令，删除了其中的大部分。多亏了保护，他们并没有立即消失，但他们在一个危险的状态下徘徊。任何对绑定pvc的POD的删除或重新启动都会导致删除
kubernetes.io/pvc保护
终结器，从而删除底层卷（在我们的示例中为EBS）。当资源处于终止状态时，也不能添加新的终结器-从k8s设计的角度来看，这是防止争用条件所必需的

以下是我遵循的步骤：


备份您关心的存储卷。这只是为了防止可能的删除—AWS、GCP、Azure都提供了执行此操作并创建新快照的机制
直接访问etcd—如果它作为静态pod运行，您可以通过ssh连接到它并检查http服务端口。默认情况下，这是4001。如果正在运行多个etcd节点，请使用任意一个
将4001端口从吊舱向前移动到您的机器


使用RESTAPI或类似工具连接到集群

导航到
/registry/persistentvolumes/
，并找到相应的PV。k8s中控制器对资源的删除是通过设置控制器规范中的
.spec.deletionTimeStamp
字段来完成的。删除此字段可使控制器停止尝试删除PV。这将使它们恢复到
绑定
状态，这可能是运行删除之前的状态

您还可以仔细编辑回收策略，以
保留
，然后将对象保存回etcd。控制器将很快重新读取状态，您很快就会看到它反映在
kubectl get pv
输出中


您的PV应返回到旧的未删除状态：

$ kubectl get pv

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                                             STORAGECLASS                      REASON    AGE
pvc-b5adexxx   5Gi        RWO            Retain           Bound     zookeeper/datadir-zoo-0                           gp2                                         287d
pvc-b5ae9xxx   5Gi        RWO            Retain           Bound     zookeeper/datalogdir-zoo-0                        gp2                                         287d

作为一般最佳做法，最好使用正确的永久卷回收策略，以防止意外删除PV或底层存储。
编辑：这仅适用于删除PVC而不是PV的情况。如果您删除了PV本身，请不要按照这些说明操作，否则磁盘可能会被删除

由于一个粗心的错误，我发现自己处于同样的境地。它在Google Cloud/GKE上设置了一个statefulset。我的PVC说终止，因为引用它的pod仍在运行，并且PV配置了Deleted的retain策略。最后，我找到了一种更简单的方法来解决所有问题，它还保留了所有额外的Google/Kubernetes元数据和名称

首先，我会按照另一位answ的建议为您的磁盘制作快照
$ kubectl get pv

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                                             STORAGECLASS                      REASON    AGE
pvc-b5adexxx   5Gi        RWO            Retain           Bound     zookeeper/datadir-zoo-0                           gp2                                         287d
pvc-b5ae9xxx   5Gi        RWO            Retain           Bound     zookeeper/datalogdir-zoo-0                        gp2                                         287d

    kubectl get pv

    kubectl patch pv <your-pv-name-goes-here> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"

    kubectl edit pv <your-pv-name-goes-here>

      claimRef:
        apiVersion: v1
        kind: PersistentVolumeClaim
        name: my-app-pvc-my-app-0
        namespace: default
        resourceVersion: "1234567"
        uid: 12345678-1234-1234-1234-1234567890ab