Kubernetes中删除Pod之后的PV/PVC状态 [英] State of PV/PVC after Pod is Deleted in Kubernetes

问题描述

我有一个Kubernetes集群，其中部署了一些Pod(DB，Frontend，Redis).我无法完全掌握的部分是删除了pod后PVC会发生什么情况.

例如，如果我删除绑定到CLAIM_A的POD_A，我知道CLAIM_A不会自动删除.如果再尝试重新创建POD，则会将其附加到同一PVC上，但所有数据都将丢失.

任何人都可以解释发生了什么，我看过官方文档，但目前没有任何意义.

感谢您的帮助.

解决方案

PVC的寿命独立于豆荚.如果 PV 仍然存在，则可能是因为其ReclaimPolicy设置为Retain情况下，即使PVC消失了也不会被删除.

PersistentVolume可以具有各种回收策略，包括保留"，回收"和删除".对于动态配置的PersistentVolume，默认回收策略为删除".这意味着，当用户删除相应的PersistentVolumeClaim时，将自动删除动态预配置的卷.如果卷中包含宝贵的数据，则这种自动行为可能是不合适的.请注意， RECLAIM POLICY 是删除"(默认值)，这是两个回收策略之一，另一个是保留".(不建议使用第三个策略回收).如果是删除，则在删除PVC时会自动删除PV，并且PVC上的数据也会丢失.

在这种情况下，使用保留"策略更为合适.使用保留"策略，如果用户删除PersistentVolumeClaim，则不会删除相应的PersistentVolume.而是将其移至发布"阶段，在该阶段可以手动恢复其所有数据.

当持久卷受到保护时，这也可能发生.您应该可以交叉验证:

命令:

  $ kubectl描述pvc PVC_NAME |grep终结器 

输出:

 最终确定者:[kubernetes.io/pvc-protection] 

您可以通过使用kubectl补丁将终结器设置为null来解决此问题:

  $ kubectl补丁pvc PVC_NAME -p'{元数据":{"finalizers":[]}}'--type = merge 

PersistentVolume可以通过资源提供者支持的任何方式安装在主机上.每个PV都有自己的一组访问模式，用于描述该特定PV的功能.

访问方式为:

• ReadWriteOnce –该卷可以通过单个读写方式安装节点
• ReadOnlyMany –该卷可以被许多节点只读装载
• ReadWriteMany –该卷可以被许多节点读写安装

在CLI中，访问模式缩写为:

• RWO-ReadWriteOnce
• ROX-ReadOnlyMany
• RWX-ReadWriteMany

因此，如果重新创建了pod和调度程序，则将其放置在其他节点上，并且PV的回收策略已设置为ReadWriteOnce.通常，您无法访问数据.

在使用特定访问模式请求存储时，声明使用与卷相同的约定.我的建议是将PV访问模式编辑为ReadWriteMany.

  $ kubectl编辑pv your_pv 

您应该如下所示更新PersistentVolume中的访问模式

  accessModes:-ReadWriteMany 

I have a Kubernetes cluster with some pods deployed (DB, Frontend, Redis). A part that I can't fully grasp is what happens to the PVC after the pod is deleted.

For example, if I delete POD_A which is bound to CLAIM_A I know that CLAIM_A is not deleted automatically. If I then try to recreate the POD, it is attached back to the same PVC but the all the data is missing.

Can anyone explain what happens, I've looked at the official documentation but not making any sense at the moment.

Any help is appreciated.

解决方案

PVCs have a lifetime independent of pods. If PV still exists it may be because it has ReclaimPolicy set to Retain in which case it won't be deleted even if PVC is gone.

PersistentVolumes can have various reclaim policies, including "Retain", "Recycle", and "Delete". For dynamically provisioned PersistentVolumes, the default reclaim policy is "Delete". This means that a dynamically provisioned volume is automatically deleted when a user deletes the corresponding PersistentVolumeClaim. This automatic behavior might be inappropriate if the volume contains precious data. Notice that the RECLAIM POLICY is Delete (default value), which is one of the two reclaim policies, the other one is Retain. (A third policy Recycle has been deprecated). In case of Delete, the PV is deleted automatically when the PVC is removed, and the data on the PVC will also be lost.

In that case, it is more appropriate to use the "Retain" policy. With the "Retain" policy, if a user deletes a PersistentVolumeClaim, the corresponding PersistentVolume is not be deleted. Instead, it is moved to the Released phase, where all of its data can be manually recovered.

This may also happens too when persistent volume is protected. You should be able to cross verify this:

Command:

$ kubectl describe pvc PVC_NAME | grep Finalizers

Output:

Finalizers:    [kubernetes.io/pvc-protection]

You can fix this by setting finalizers to null using kubectl patch:

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

EDIT:

A PersistentVolume can be mounted on a host in any way supported by the resource provider. Each PV gets its own set of access modes describing that specific PV’s capabilities.

The access modes are:

• ReadWriteOnce – the volume can be mounted as read-write by a single node
• ReadOnlyMany – the volume can be mounted read-only by many nodes
• ReadWriteMany – the volume can be mounted as read-write by many nodes

In the CLI, the access modes are abbreviated to:

• RWO - ReadWriteOnce
• ROX - ReadOnlyMany
• RWX - ReadWriteMany

So if you recreated pod and scheduler put it on different node and your PV has reclaim policy set to ReadWriteOnce it is normal that you cannot access your data.

Claims use the same conventions as volumes when requesting storage with specific access modes. My advice is to edit PV access mode to ReadWriteMany.

$ kubectl edit pv your_pv

You should be updating the access mode in PersistentVolume as shown below

   accessModes:
      - ReadWriteMany

这篇关于Kubernetes中删除Pod之后的PV/PVC状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！