Kubernetes中使用PersistentVolume挂载云盘

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

    spec:
      containers:
      - name: logs
	   # 挂载
        volumeMounts:
        - name: varlog
          mountPath: /tmp/log
      # 定义本地存储
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
1
2
3
4
5
6
7
8
9
10
11
12

为了实现容器存储与计算的分离，可将容器的数据单独存放到**网络共享存储(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
1
2
3
4
5
6
7
8
9

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

yum install -y nfs-utils
1

最后就可以使用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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

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
1
2
3
4
5
6
7
8
9
10
11
12
13

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

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  # 访问模式；描述用户应用对存储资源的访问权限
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      # 资源请求的存储大小
      storage: 5Gi
1
2
3
4
5
6
7
8
9
10
11
12

其中，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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

2.2 PV和PVC的生命周期

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

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

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

1. 资源供应：通过PV建立对不同磁盘资源的描述，提供PV资源给消费者使用
2. 资源绑定：创建好PVC后，PVC会在已存在的PV中选择合适的PV进行绑定，绑定成功，状态变成Bound，且该PV被对应的PVC独占绑定，不可以再被其他PVC绑定，除非该PVC释放。若在k8s系统中没有找到合适的PV，则PVC一直处于Pending状态。
3. 资源使用：在通过Deployment创建容器时，在spec.template.spec.volumes进行磁盘挂载时选择persistentVolumeClaim挂载到对应的PVC。
4. 资源释放：删除PVC，与该PVC绑定的PV状态就会变成“Released”，该PVC在存储设备上的数据删除后，对应的PV才能与其他的PVC进行绑定。
5. 资源回收：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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

之后定义 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

动态绑定

上面的手动绑定无法根据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
1
2
3
4
5
6
7
8
9
10
11
12

然后创建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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

可以看到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
1
2
3
4
5
6
7