首页 > 网站技巧 > 服务器 > 云和虚拟化 > 云其它 > Kubernetes使用PersistentVolume挂载云盘

Kubernetes中使用PersistentVolume挂载云盘方式

2024-02-27 09:40:59 作者：Vic·Tory

这篇文章主要介绍了Kubernetes中使用PersistentVolume挂载云盘方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教

Kubernetes中可用将本地磁盘作为存储挂载到容器上，但这样做的弊端是当容器出现异常而重启之后数据也会随之消失

    spec:
      containers:
      - name: logs
	   # 挂载
        volumeMounts:
        - name: varlog
          mountPath: /tmp/log
      # 定义本地存储
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

为了实现容器存储与计算的分离，可将容器的数据单独存放到**网络共享存储(Network File System，NFS)**服务器上，当容器挂掉之后并不会影响到数据，之后容器重启或一个新的容器连接到服务器后可以重新读取到数据

1 NFS的使用

首先需要将一台服务器配置为NFS服务器

# 安装nfs
yum install -y nfs-utils
# 创建存放数据的目录
mkdir -p /data/nfs
# 创建并设置挂载路径
vim /etc/exports
/data/nfs *(rw,no_root_squash)
# 启动服务
systemctl start nfs

之后在K8s集群的Node节点上也安装nfs服务

yum install -y nfs-utils

最后就可以使用nfs作为数据挂载点了，在其中定义nfs服务器的地址server和其上面的存储路径path。

通过如下配置文件就将pod中的 /usr/share/nginx/html 挂载到了 192.168.44.134/data/nfs

    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        # 挂载nfs
        - name: mynfs
          mountPath: /usr/share/nginx/html
        ports:
        - containerPort: 80
      volumes:
      # 定义nfs数据挂载点
        - name: mynfs
          nfs:
            server: 192.168.44.134
            path: /data/nfs

2 PV与PVC

上面的nfs挂载时ip 和端口是直接写在容器yaml文件中的，这样管理起来可能不方便。PV 和 PVC 是持久性存储的概念，它们可帮助我们在集群中管理持久性存储，使数据更加稳定可靠：

1.PV（Persistent Volume）：一个抽象的存储资源，可以由管理员预先设置，并由集群中的一个 Pod 来使用。它可以是磁盘，NFS 共享或云存储等存储资源。PV 可以被动态或静态地绑定到一个 PVC 上，以供 Pod 使用。

2.PVC（Persistent Volume Claim）：一个声明，它请求一个特定的 PV 资源。PVC 定义了我们所需的存储容量、访问模式、数据持久性和其他细节，从而与 PV 进行匹配。当 PVC 绑定到 PV 上时，它就可以被 Pod 使用了。

2.1 使用

如下所示PV定义文件mypv.yaml，在其中定义其存储大小、路径等信息，通过kubectl apply -f mypv.yaml创建PV

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  nfs:
  	# 定义PV的存储路径
    path: /k8s/nfs
    server: 192.168.44.134

创建PVC，系统会自动选择合适的PV分配给它进行绑定，可以在其中定义需要的存储容量、访问模式等信息

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  # 访问模式；描述用户应用对存储资源的访问权限
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      # 资源请求的存储大小
      storage: 5Gi

其中，accessModes有如下三种模式

RWO：ReadWriteOnce，仅允许单个节点挂载进行读写；
ROX：ReadOnlyMany，允许多个节点挂载且只读；
RWX：ReadWriteMany，允许多个节点挂载进行读写；

最后在创建容器时就可以通过PVC的方式挂载存储，不必关心其底层存储PV的实现细节

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-dep1
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - name: wwwroot
          mountPath: /usr/share/nginx/html
        ports:
        - containerPort: 80
      volumes:
      - name: wwwroot
        # 挂载到my-pvc
        persistentVolumeClaim:
          claimName: my-pvc

2.2 PV和PVC的生命周期

如图所示，PVC在与PV绑定之后状态就会变为Bound，PVC一共有如下几种状态：

Available：可用状态，无PV绑定；
Bound：绑定状态，已经和某个PV绑定；
Released：释放状态，被绑定的PV已删除，资源释放，但没有被集群回收；
Failed：失败状态，自动资源回收失败；

如下所示，容器Pod经过PVC -> PV 使用存储资源，其生命周期可以分为供应、绑定、使用、释放和回收

资源供应：通过PV建立对不同磁盘资源的描述，提供PV资源给消费者使用
资源绑定：创建好PVC后，PVC会在已存在的PV中选择合适的PV进行绑定，绑定成功，状态变成Bound，且该PV被对应的PVC独占绑定，不可以再被其他PVC绑定，除非该PVC释放。若在k8s系统中没有找到合适的PV，则PVC一直处于Pending状态。
资源使用：在通过Deployment创建容器时，在spec.template.spec.volumes进行磁盘挂载时选择persistentVolumeClaim挂载到对应的PVC。
资源释放：删除PVC，与该PVC绑定的PV状态就会变成“Released”，该PVC在存储设备上的数据删除后，对应的PV才能与其他的PVC进行绑定。
资源回收：PV中可以通过spec.persistentVolumeReclaimPolicy设置回收策略，用于在绑定的PVC删除后，资源释放后如何处理PVC写入存储设备的数据：
Retain：保留，删除PVC后，PV保留数据；
Recycle：回收空间，删除PVC后，简单的清除文件；（NFS和HostPath存储支持）
Delete：删除，删除PVC后，与PV相连接的后端存储会删除数据；（AWS EBS、Azure Disk、Cinder volumes、GCE PD支持）

2.3 PV与PVC的绑定

PV与PVC之间可以通过静态绑定或者动态绑定建立连接：

静态模式就是集群管理员预先创建对应的PV对存储特性进行设置；
动态模式就是管理员预先创建好StorageClass资源对后端存储进行描述，PVC创建时对存储类型进行声明，k8s会自动创建合适的PV与PVC进行绑定。

手动绑定

如下所示，首先定义一个test-pv1

[root@k8s /pv_test]#  vim test_pv1.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:
	# 定义PV的名字
  name: test-pv1
  labels:
    pv: test-pv1
spec:
  capacity:
    storage: 2Mi
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /date-nfs/k8s
    server: 10.139.12.14

之后定义 PVC，在其中通过spec.selector.matchLabels标签匹配上面定义的test-pv1

[root@k8s /pvc_test]#  vim test_pvc1.yaml 
#persistent Volume Claim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc1
  namespace: t1
spec:
  #storageClassName: managed-nfs-storage
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Mi
  selector:
    # 手动进行绑定
    matchLabels:
      pv: test-pv1

动态绑定

上面的手动绑定无法根据PVC的访问模式，容量大小等实际需要灵活地匹配到合适的PV，每次去手动选择或创建PV会变得十分繁琐。

这时可以通过StorageClass根据pvc定义的来动态创建合适的pv，不仅节省了管理员的时间，还可以封装不同类型的存储供pvc选用。

如下所示通过StorageClass将PVC和PV进行自动绑定的过程

首先创建一个StorageClass

[root@master1 sc]# cat nfs-sc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: statefu-nfs
  namespace: default
# 云盘资源提供方
provisioner: nfs-deploy     
reclaimPolicy: Retain

[root@master1 sc]# kubectl apply -f nfs-sc.yaml
storageclass.storage.k8s.io/statefu-nfs created

然后创建PVC，在其中配置spec.storageClassName为上面的创建的statefu-nfs。

[root@master1 sc]# cat test-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-claim
  namespace: default
spec:
  storageClassName: statefu-nfs   #sc一定要指向上面创建的sc名称
  accessModes:
    - ReadWriteMany   #采用ReadWriteMany的访问模式
  resources:
    requests:
      storage: 1Gi
      
[root@master1 sc]# kubectl apply -f test-pvc.yaml

可以看到PVC test-claim创建成功之后，随之自动创建了对应的PV并且绑定到了test-claim

[root@master1 sc]# kubectl get pvc
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-claim   Bound    pvc-0b9e1107-fefc-48b9-a5ec-8f8690e94435   1Gi        RWX            statefu-nfs    107m

[root@master1 sc]# kubectl get pv
NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
pvc-0b9e1107-fefc-48b9-a5ec-8f8690e94435  1Gi  RWX  Delete   Bound   default/test-claim statefu-nfs          107m

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。