pv和pvc状态

原文地址：https://kubernetes.cn/topics/46

API Server 和 PVController

API Server: 这个组件提供对API的支持，响应REST操作，验证API模型和更新etcd中的相应对象

PVController: 是ontroller.volume.persistentvolume.PersistentVolumeController的简称，负责监听PV和PVC资源的改动Event，取得最新的PV和PVC并维护它们之间的绑定关系。

通常情况下API Server和PVController是运行在一个进程里的，但它们之间通过Rest API通讯，理论上支持分开部署。

K8s里的业务逻辑处理都是在不同的Controller组件里进行，例如大家耳熟能详的Replication Controller，NodeController等。

下图是对这个过程的简单描述：

PV 和 PVC状态图

在我们开始深入PVController细节之前有必要先了解一下PV和PVC的状态切换。可参考前一篇文章了解所有状态的集合。

PV的状态图：

PVC的状态图：

实例演示

为了让大家有更直观的感受，现在我们用一个真实的实例并结合etcd里数据的变化来更好的理解各种状态的切换过程。

结合上面的PV和PVC状态图，这个实例唯一没有覆盖的路径是PV状态图中的序号3（Released到Available），有兴趣的用户可以自行做实验，只要保证PV中的Storage是真实可用的能被Mount到节点上就行。

操作 PV状态 PVC状态
1. 添加PV Available -
2. 添加PVC Available Pending
  Bound Bound
3. 删除PV - Lost
4. 再次添加PV Bound Bound
5. 删除PVC Released -
6. Storage不可用 Failed -
7. 手动修改PV，删除ClaimRef Available -

下面我会把每步操作后etcd里PV和PVC的关键信息抽取出来，为了避免冗长，只显示和状态相关的信息。

1. 添加PV

刚添加的PV在未被绑定到PVC时是Available状态,为了待会模拟PV由Released变为Failed的状态，这里故意把nfs server ip设置为非法地址。

[[email protected] pv]# kubectl get pv pv3 -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
creationTimestamp: 2017-02-16T08:33:43Z
name: pv3
...
spec:
accessModes:
- ReadWriteOnce
- ReadWriteMany
- ReadOnlyMany
capacity:
storage: 5Gi
nfs:
path: /var/nfsshare/v1
server: 172.16.51.58.1
persistentVolumeReclaimPolicy: Recycle
status:
phase: Available
2. 添加PVC

刚添加的PVC的状态是Pending，如果有合适的PV，这个Pending状态会立刻变为Bound，同时相应的PVC也会变为Bound。 你也可以先添加PVC，后添加PV，这样就能保证看到Pending状态。

[[email protected] pv]# kubectl get pvc myclaim -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
creationTimestamp: 2017-02-16T08:45:53Z
name: myclaim
namespace: test
...
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
  storage: 5Gi
status:
phase: Pending

然后PV和PVC都变为Bound：

[[email protected] pv]# kubectl get pvc myclaim -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
pv.kubernetes.io/bind-completed: "yes"
...
uid: 534338ef-f424-11e6-8ab8-000c29a5bb07
spec:
...
status:
...
phase: Bound

[[email protected] pv]# kubectl get pv pv3 -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
annotations:
pv.kubernetes.io/bound-by-controller: "yes"
...
name: pv3
...
spec:
...
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: myclaim
namespace: test
uid: 534338ef-f424-11e6-8ab8-000c29a5bb07
persistentVolumeReclaimPolicy: Recycle
status:
phase: Bound
3. 删除PV

删除PV后,PVC状态变为Lost。请看PVC状态图，Lost状态是没办法变回Pending的，这是即使有其它可用的PV，也不能被PVC使用，因为PVC中还保留对PV的引用（volumeName:pv3）。

[[email protected] pv]# kubectl delete pv pv3
persistentvolume "pv3" deleted
[[email protected] pv]# kubectl get pvc myclaim -o yaml
...
spec:
volumeName: pv3
status:
phase: Lost
4. 再次添加PV

再次把刚才的PV添加回来后，PV会被自动绑定到PVC，PVC再次变为Bound。

[[email protected] pv]# kubectl create -f 1.yaml
persistentvolume "pv3" created
[[email protected] pv]# kubectl get pvc myclaim -o yaml
...
phase: Bound
5. 删除PVC

删除PVC后，PV状态变为Released，请注意这时PV中还保留对PVC的引用（spec.claimRef）。

[[email protected] pv]# kubectl delete pvc myclaim
persistentvolumeclaim "myclaim" deleted
[[email protected] pv]# kubectl get pv pv3 -o yaml
...
spec:
accessModes:
- ReadWriteOnce
- ReadWriteMany
- ReadOnlyMany
capacity:
storage: 5Gi
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: myclaim
...
persistentVolumeReclaimPolicy: Recycle
status:
phase: Released
6. Storage不可用

如果PV的ReclaimPolicy是Recycle，系统会试图mount真实的存储并做删除操作（rm -rm /volume/*）,因为我们配置了错误的存储server，Recycle会失败。

[[email protected] pv]# kubectl get pv pv3 -o yaml
...
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: myclaim
...
phase: Failed
7. 手动修改PV，删除ClaimRef

这时就需要手工干预了，真实生产环境下管理员会把数据备份或迁移出来，然后修改PV，删除claimRef对PVC的引用，k8s会接受到PV变化的Event，将PV状态修改为Available。

[[email protected] pv]# kubectl edit pv pv3
persistentvolume "pv3" edited
[[email protected] pv]# kubectl get pv pv3 -o yaml
...
status:
phase: Available

PVController 构建和启动

构建

构建过程会创建PVController运行所需要的所有子组件，为了便于理解，这里省去了参数的传递过程，在代码片段里也只是保留了主要的逻辑处理，有兴趣的用户可以自行下载代码研究。

func NewPersistentVolumeController(
kubeClient clientset.Interface,
syncPeriod time.Duration,
alphaProvisioner vol.ProvisionableVolumePlugin,
volumePlugins []vol.VolumePlugin,
cloud cloudprovider.Interface,
clusterName string,
volumeSource, claimSource, classSource cache.ListerWatcher,
eventRecorder record.EventRecorder,
enableDynamicProvisioning bool,
) *PersistentVolumeController {

// eventRecorder 用于记录异常和关键信息，以Event资源形式记录在API Server并和event的来源建立绑定关系，
// 用kubectl describe 可以看到某种Resource上的event。

if eventRecorder == nil {
    broadcaster := record.NewBroadcaster()
    broadcaster.StartRecordingToSink(&unversioned_core.EventSinkImpl{Interface: kubeClient.Core().Events("")})
    eventRecorder = broadcaster.NewRecorder(api.EventSource{Component: "persistentvolume-controller"})
}

// 初始化一个新的PVController实例，volumes用于缓存最新的PV，claims用于缓存最新的PVC。
// kubeClient用于和API Server交互。

controller := &PersistentVolumeController{
    volumes:           newPersistentVolumeOrderedIndex(),
    claims:            cache.NewStore(framework.DeletionHandlingMetaNamespaceKeyFunc),
    kubeClient:        kubeClient,
    eventRecorder:     eventRecorder,
...
}

// volumeSource 主要有两个功能：1. 用于请求API Server 得到最新的PV列表。 2. 用于接收API Server发过来的PV变动的Event
//
if volumeSource == nil {
    volumeSource = &cache.ListWatch{
        ListFunc: func(options api.ListOptions) (runtime.Object, error) {
            return kubeClient.Core().PersistentVolumes().List(options)
        },
        WatchFunc: func(options api.ListOptions) (watch.Interface, error) {
            return kubeClient.Core().PersistentVolumes().Watch(options)
        },
    }
}
controller.volumeSource = volumeSource

//claimSource 主要有两个功能：1. 用于请求API Server 得到最新的PVC列表。 2. 用于接收API Server发过来的PVC变动的Event
//
if claimSource == nil {
    claimSource = &cache.ListWatch{
        ListFunc: func(options api.ListOptions) (runtime.Object, error) {
            return kubeClient.Core().PersistentVolumeClaims(api.NamespaceAll).List(options)
        },
        WatchFunc: func(options api.ListOptions) (watch.Interface, error) {
            return kubeClient.Core().PersistentVolumeClaims(api.NamespaceAll).Watch(options)
        },
    }
}
controller.claimSource = claimSource

...

// volumeController会被启动为一个GoRoutine（类似线程，但更轻量），接收并处理PV的add/delete/update Event
//
_, controller.volumeController = framework.NewIndexerInformer(
    volumeSource,
    &api.PersistentVolume{},
    syncPeriod,
    framework.ResourceEventHandlerFuncs{
        AddFunc:    controller.addVolume,
        UpdateFunc: controller.updateVolume,
        DeleteFunc: controller.deleteVolume,
    },
    cache.Indexers{"accessmodes": accessModesIndexFunc},
)

// claimController会被启动为一个GoRoutine，接收并处理PVC的add/delete/update Event
//
_,controller.claimController=framework.NewInformer(claimSource,&api.PersistentVolumeClaim{},syncPeriod,framework.ResourceEventHandlerFuncs{AddFunc:controller.addClaim,UpdateFunc:controller.updateClaim,DeleteFunc:controller.deleteClaim,},)...returncontroller}
启动

启动过程比较简单，只是把volumeController和claimController启动到新的Goroutine里，这两个子Controller开始接收PV和PVC更新的Event并会触发相应的处理。 从构建过程可以看出：这两个子Controller会处理六种Event通知，分别是PV的add/delete/update和PVC的add/delete/update.

// Run starts all of this controller‘s control loops
func (ctrl *PersistentVolumeController) Run(stopCh <-chan struct{}) {
glog.V(4).Infof("starting PersistentVolumeController")
ctrl.initializeCaches(ctrl.volumeSource, ctrl.claimSource)
go ctrl.volumeController.Run(stopCh)
go ctrl.claimController.Run(stopCh)
}

PVController 工作流程解析

这部分会介绍PVController的主要职责，处理上面提到的六种Event通知,重新计算PV和PVC的绑定关系并把绑定关系通过API Server持久化。

add/delete/update PV

这三个方法都是先把Event中的最新PV更新到缓存中，然后调用syncVolume处理。可见syncVolume是一个通用的方法，逻辑比较复杂，因为要考虑到所有可能的PV更新类型。

说明：

unbindPV 会删除PV中对PV的引用然后调用API Server持久化，API Server会再生成一个PV更新的Event并通知PVController，从而使syncVolume再次被调用，但是这次会走不同的分支并把PV设置为Released

Fun:storeObjectUpdate 会更新本地缓存和API Server

Fun: reclaimVolume 的详情如下图：

add/delete/update PVC

这三个方法都是先把Event中的最新PVC更新到缓存中，然后调用syncClaim处理。

时间： 2024-10-09 10:44:52

pv和pvc状态的相关文章

Kubernetes 中的pv和pvc

原文地址:http://www.cnblogs.com/leidaxia/p/6485646.html 持久卷 PersistentVolumes 本文描述了 Kubernetes 中的 PersistentVolumes.要求读者有对卷 (volumes) 所有了解. 简介 存储管理跟计算管理是两个不同的问题.PersistentVolume 子系统,对存储的供应和使用做了抽象,以 API 形式提供给管理员和用户使用.要完成这一任务,我们引入了两个新的 API 资源:PersistentVol

浅析kubernetes创建Pv、Pvc、Deployment

基本环境 #系统环境 cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) #k8s client 和 server 的版本信息 kubectl version Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322

PV、PVC和Storeclass等官方内容翻译

k8s1.13版本 PV apiVersion: v1 kind: PersistentVolume metadata: name: filesystem-pvc spec: capacity: #未来的属性可能包括 IOPS.吞吐量等 storage: 5Gi volumeMode: Filesystem #volumeMode 的有效值可以是“Filesystem”或“Block”.如果未指定,volumeMode 将默认为“Filesystem”.这是一个可选的 API 参数 access

Kubernetes 系列（六）:持久化存储 PV与PVC（一）

在使用容器之后,我们需要考虑的另外一个问题就是持久化存储,怎么保证容器内的数据存储到我们的服务器硬盘上.这样容器在重建后,依然可以使用之前的数据.但是显然存储资源和 CPU 资源以及内存资源有很大不同,为了屏蔽底层的技术实现细节,让用户更加方便的使用,Kubernetes便引入了 PV 和 PVC 两个重要的资源对象来实现对存储的管理. 一.概念 PV 的全称是:PersistentVolume(持久化卷),是对底层的共享存储的一种抽象,PV 由管理员进行创建和配置,它和具体的底层的共享存储技术

k8s存储数据持久化，emptyDir，hostPath，基于Nfs服务的PV，PVC

在docker和K8S中都存在容器是有生命周期的,因此数据卷可以实现数据持久化. 数据卷解决的主要问题: 1.数据持久性:当我们写入数据时,文件都是暂时性的存在,当容器崩溃后,host就会将这个容器杀死,然后重新从镜像创建容器,数据就会丢失. 2.数据共享:在同一个Pod中运行容器,会存在共享文件的需求. 数据卷的类型: 1.emptyDiremptyDir数据卷类似于docker数据持久化的docker manager volume,该数据卷初分配时,是一个空目录,同一个Pod中的容器可以对该

k8s数据持久化之statefulset的数据持久化，并自动创建PV与PVC

一:Statefulset StatefulSet是为了解决有状态服务的问题,对应的Deployment和ReplicaSet是为了无状态服务而设计,其应用场景包括:1.稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现2.稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现3.有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依

MySQL 如何使用 PV 和 PVC？- 每天5分钟玩转 Docker 容器技术（154）

本节演示如何为 MySQL 数据库提供持久化存储,步骤为: 创建 PV 和 PVC. 部署 MySQL. 向 MySQL 添加数据. 模拟节点宕机故障,Kubernetes 将 MySQL 自动迁移到其他节点. 验证数据一致性. 首先创建 PV 和 PVC,配置如下: mysql-pv.yml mysql-pvc.yml 创建 mysql-pv 和 mysql-pvc: 接下来部署 MySQL,配置文件如下: PVC mysql-pvc Bound 的 PV mysql-pv 将被 mount

Kubernetes中的PV和PVC是啥

引入了一组叫作Persistent Volume Claim(PVC)和Persistent Volume(PV)的API对象,大大降低了用户声明和使用持久化Volume的门槛. 在Pod的Volumes中,只要声明类型是persistentVolumeClaim,指定PVC的名字,当创建这个PVC对象,k8s就自动为它绑定一个符合条件的Volume,这个Volume,从PV来 PVC和PV的设计,类似"接口"和"实现"的思想,开发者只知道使用"接口&qu

?mysql使用pv和pvc实践操作记录

创建nfs存储目录 [[email protected] ~]# mkdir /data/k8s/mysqlpv1 创建pv [[email protected] ~]# cat mysql-pv.yml apiVersion: v1 kind: PersistentVolume metadata: name: mysqlpv1 spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPol