Kubernetes数据管理

kubernetes ginotang 1937℃ 0评论

简介

Pod中的数据默认并没有进行持久化,它们会随着Pod的销毁而一同被消灭。 我们都知道,Pod并不总是稳定可靠的,它有可能会被频繁销毁并重建,我们并不希望重要的数据(例如MySQL中的数据)跟着Pod一同被销毁。这就需要引入一种持久的存储系统。

Volume和Persistent Volume

Kubernetes提供了两种储存介质,它们是Volume和Persistent Volume。简单来说,Volume中的数据不能被持久化,Pod销毁,数据消失;而Persistent Volume中的数据则独立于Pod,即使Pod销毁,数据依然可以永久保存,除非你不希望。

注意:Volume的生命周期和Pod一样长,它对应的是Pod,而不是容器。即数据在容器重启过程中依然保留下来,除非Pod被销毁

常用的(Persistent)Volume

除了一些云平台提供的Volume,以下几种Volume类型是最常用的

  • emptyDir(非Persistent Volume)
  • hostPath (Persistent Volume)
  • nfs( Persistent Volume)

emptyDir:和Docker中的的匿名Volume比较类似,当我们指定使用emptyDir作为储存的时候,它会和Pod一起被初始化,并且随着Pod的销毁而销毁。因此,emptyDir比较适合于容器间的临时数据交换。

hostPath:通常是Host主机中的一个目录,数据持久性比emptyDir好,即使Pod被销毁,数据依然存在。hostPath适合需要从文件系统读取配置的Pod,例如Kubernetes的一些核心组件;用于监控的Pod如cAdvisor等。

nfs:网络文件系统,当Pod销毁,只是单纯卸载nfs的挂载点,并不会把数据删除,因此同样可用于数据持久化。

emptyDir和hostPath通常由Host主机提供储存设备,属于内部储存设备,因此Pod对它们有一定的依赖性,而nfs是一种网络文件系统,属于外部储存设备,可以跨网络访问,因此它的依赖性相对来说更小,移植性更好。

使用Volume

.spec.volumes指定提供的volume类型

.spec.containers.volumeMounts指定volume在容器中的挂载点

下面我们创建包含两个容器的Pod(vol.yaml)

准备好之后使用kubectl apply -f vol.yaml命令创建资源。Pod中的两个容器使用的是相同的volume,可以通过下面的命令查看

返回的结果中关于Mounts的部分信息如下

可见它们确实使用了同一个volume保存数据。

emptyDir的使用相当于执行了docker run -v /tmp命令。

使用Persistent Volume的两种方式

hostPath和nfs都属于Persistent Volume,可以通过两种方式使用它们

  • 方法一:和emptyDir使用相同的方法,即通过.spec.volumes.spec.containers.volumeMounts
  • 方法二:依赖于方法一,通过persistentVolumepersistentVolumeClaim关键字,但更灵活

方法一

用hostPath作为例子,把宿主机中的/home/storage目录挂载到容器中。

创建Pod的文件(hostpath.yaml)

创建Pod并等待它执行完毕,到Pod所在的主机查看/home/storage下是否有test.txt文件。

方法二

方法二使用的是persistentVolume(PV)和persistentVolumeClaim(PVC),那么它们是什么?简单来说persistentVolume用于定义存储设备,而persistentVolumeClaim则用于向已有设备申请存储空间。如图(图片来自网络)

persistentVolumeClaim

它们带来的好处是职责划分:管理员负责管理储存设备和空间的划分,开发者不需要了解过多的细节,只管申请空间即可。

用nfs来作为例子,master提供nfs储存空间

注意:kubernetes节点如果要正常挂载nfs,需要安装nfs-utils(centos7)

创建persistentVolume

nfspv.yaml文件的内容

上面的文件创建了一个容量1G的PV。

accessModes指定了PV的访问模式,可选的模式有

  • ReadWriteOnce – PV 能以 read-write 模式 mount 到单个节点。
  • ReadOnlyMany – PV 能以 read-only 模式 mount 到多个节点。
  • ReadWriteMany – PV 能以 read-write 模式 mount 到多个节点。

persistentVolumeReclaimPolicy指定了PV的回收策略,可选的策略有

  • Retain – 需要管理员手工回收。
  • Recycle – 清除 PV 中的数据,效果相当于执行 rm -rf /thevolume/*
  • Delete – 删除 Storage Provider 上的对应存储资源,例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

storageClassName指定了PV的分类,它可以是任意值,只要语义明确即可。

然后就是通过apply命令创建PV

创建PersistentVolumeClaim

PVC的创建比PV稍微简单(nfspvc.yaml)

storageClassName中的值和PV中的对应

当PVC创建完成,再次查看PV的状态,已经变为Bound,且已经被nfspvc申请使用。

在Pod中使用储存空间

PVC创建好之后,Pod就可以引用这部分的储存容量(nfspod.yaml)

相比起第一种方法而言,这种方法中的volumes字段没有直接创建储存设备,而是通过persistentVolumeClaim间接使用了我们定义好的储存设备。

如果发现mysql启动失败,提示/var/lib/mysql没有操作权限,请在nfs配置文件/etc/exports中添加no_root_squash

回收PersistentVolume

当储存空间不再需要时,可以通过删除PVC进行回收。

Kubernetes会根据PV的回收策略判断是否需要删除数据,因为之前我们设置的策略是Retain,因此数据得以保留,如果是Recycle,那么数据就会被清除。

删除任何PVC之前记得确保它们没有被引用,否则删除的时候它们的状态一直停留在terminating导致删除失败。

动态PV

动态PV是指使用PVC之前不需要创建PV,而是在PVC申请存储空间的时候自动根据条件创建,也叫做动态供给(Dynamical Provision)。动态供给的基础是StorageClass,详细可参考:

Dynamical Provision

转载请注明:Pure nonsense » Kubernetes数据管理

喜欢 (1)
0 0 投票数
文章评分
订阅评论
提醒
guest
0 评论
内联反馈
查看所有评论
0
希望看到您的想法,请您发表评论x
()
x