kubernetes 使用 PV 和 PVC 管理数据存储

作者：SRE运维博客
博客地址：https://www.cnsre.cn
文章地址：https://www.cnsre.cn/posts/210903021487/
相关话题：https://www.cnsre.cn/tags/kubernetes/

容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动。其次，在 Pod 中同时运行多个容器时，这些容器之间通常需要共享文件。所以我会用 NFS 为例，创建 PV 、PVC.

PV 属于集群中的资源。PVC 是对这些资源的请求，也作为对资源的请求的检查。 PV 和 PVC 之间的相互作用遵循这样的生命周期.

PersistentVolume（PV）

PersistentVolume（PV）是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统。

PV 有两种方式来配置：静态和动态。

静态
集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中，可用于消费。
动态
根据 StorageClasses，当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，集群可能会尝试动态地为 PVC 创建卷。

安装并配置 nfs rpcbind

1
2
3
4


yum install -y nfs-utils rpcbind
mkdir -p /home/bsh/nfs
vim /etc/exports
/home/bsh/nfs *(rw,sync,no_root_squash)

配置详解：
ro	只读访问
rw	读写访问
sync	所有数据在请求时写入共享
async	NFS在写入数据前可以相应请求
secure	NFS通过1024以下的安全TCP/IP端口发送
insecure	NFS通过1024以上的端口发送
wdelay	如果多个用户要写入NFS目录，则归组写入（默认）
no_wdelay	如果多个用户要写入NFS目录，则立即写入，当使用async时，无需此设置。
Hide	在NFS共享目录中不共享其子目录
no_hide	共享NFS目录的子目录
subtree_check	如果共享/usr/bin之类的子目录时，强制NFS检查父目录的权限（默认）
no_subtree_check	和上面相对，不检查父目录权限
all_squash	共享文件的UID和GID映射匿名用户anonymous，适合公用目录。
no_all_squash	保留共享文件的UID和GID（默认）
root_squash	root用户的所有请求映射成如anonymous用户一样的权限（默认）
no_root_squas	root用户具有根目录的完全管理访问权限
anonuid=xxx	指定NFS服务器/etc/passwd文件中匿名用户的UID

启动 nfs rpcbind

1
2


systemctl enable nfs rpcbind
systemctl start nfs rpcbind

创建PV

创建 yaml 文件
vim tomcat-log-pv.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


apiVersion: v1
kind: PersistentVolume
metadata:
  name: tomcat
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /home/bsh/nfs/tomcat-log
    server: 10.0.10.51

创建 pv

1

kubectl  apply  -f  tomcat-log-pv.yaml

查看pv

1
2
3


[root@master ]# kubectl  get  pv
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
tomcat   1Gi        RWX            Retain           Available                                   26s

pv 属性详解

PV的存储容量

PV 将具有特定的存储容量。这是使用PV的capacity属性设置的。

目前，存储大小是可以设置或请求的唯一资源。未来的属性可能包括 IOPS、吞吐量等。

PV的访问模式

PersistentVolume可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能，每个 PV 的访问模式都将被设置为该卷支持的特定模式。例如，NFS 可以支持多个读/写客户端，但特定的 NFS PV 可能以只读方式导出到服务器上。每个 PV 都有一套自己的用来描述特定功能的访问模式。
存储模式包括：

ReadWriteOnce——该卷可以被单个节点以读/写模式挂载
ReadOnlyMany——该卷可以被多个节点以只读模式挂载
ReadWriteMany——该卷可以被多个节点以读/写模式挂载
在命令行中，访问模式缩写为：
RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany
一个卷一次只能使用一种访问模式挂载，即使它支持很多访问模式。例如，GCEPersistentDisk 可以由单个节点作为 ReadWriteOnce 模式挂载，或由多个节点以 ReadOnlyMany 模式挂载，但不能同时挂载
PV的回收策略
persistentVolumeReclaimPolicy属性用来指定PV的回收策略

当前的回收策略包括：

Retain（保留）——手动回收
Recycle（回收）——基本擦除（rm -rf /thevolume/*）
Delete（删除）——关联的存储资产（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）将被删除
当前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持删除策略。

storageClassName PV 可以具有一个类，通过将 storageClassName 属性设置为 StorageClass 的名称来指定该类。一个特定类别的 PV 只能绑定到请求该类别的 PVC。没有 storageClassName 的 PV 就没有类，它只能绑定到不需要特定类的 PVC。

PersistentVolumeClaim（PVC）

PersistentVolumeClaim（PVC）是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或只读多次模式挂载）。

创建PVC

创建 yaml 文件
vim tomcat-log-pvc.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: tomcat
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

创建 pv

1

kubectl  apply  -f  tomcat-log-pvc.yaml

查看pv

1
2
3


[root@master ]# kubectl  get pvc
NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
tomcat   Bound    tomcat   1Gi        RWX                           18s

使用PVC

vim tomcat.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


apiVersion: apps/v1 
kind: Deployment   
metadata:             
  name: tomcat-deployment     
  labels:       
    app: tomcat  
spec:          
  replicas: 3
  selector:      
    matchLabels: 
      app: tomcat
  minReadySeconds: 1
  progressDeadlineSeconds: 60
  revisionHistoryLimit: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:        
    metadata:  
      labels:  
        app: tomcat
    spec:         
      containers:     
      - name: tomcat     
        image: wenlongxue/tomcat:tomcat-demo-62-8fe6052    
        imagePullPolicy: Always          
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "2Gi"
            cpu: "80m"
          limits: 
            memory: "2Gi" 
            cpu: "80m"
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 180
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 30
        volumeMounts:
        - mountPath: "/usr/local/tomcat/logs"
          name: tomcat

      volumes:
      - name: tomcat
        persistentVolumeClaim:
          claimName: tomcat

部署查看 pod

1
2
3
4
5
6
7


# 部署
kubectl  apply  -f tomcat.yaml 
# 查看
kubectl  get  pods |grep  tomcat
tomcat-deployment-7588b5c8fd-4grh2       1/1     Running   0          31s
tomcat-deployment-7588b5c8fd-l89t7       1/1     Running   0          31s
tomcat-deployment-7588b5c8fd-mb8bh       1/1     Running   0          31s

最后

PVC 不关心后端存储提供者是 NFS 还是 GFS，具体使用哪种类型的存储由 PV 来定义，PVC 只和隐藏了存储实现细节的 PV 对接。
本方式为静态分配，如果有一千个 Pod，每个 Pod 有一个 PVC，那么管理员需要人工开设一千个 PV，随着集群规模的扩大，将导致无法有效管理。
K8S 提供了一种可以动态分配的工作机制，可以自动创建 PV，该机制依赖一个叫做 StorageClass 的 API 对象。