^-^
K8S数据卷详解
  1. 概述
  2. 数据卷
    1. emptyDir临时卷
    2. hostPath数据卷
    3. nfs数据卷
  3. 持久卷PV和PVC
    1. PV
    2. PVC

概述

在了解K8S的数据卷之前，先解释一下有状态容器和无状态容器的概念：

无状态容器stateless

无状态容器意味着容器上应用所使用的历史数据或运行状态不需要进行持久化，重新拉起这个应用时，无需关注这些历史输入。简单来说，例如你要运行一个计算器（而且这个计算器不需要支持历史记录功能），当你重新拉起这个计算器时，之前的数据不需要重新被加载上来，计算器可以认为是一个无状态应用。其它类似的无状态容器应用还包括一些协议转换、请求转发等应用，大体都可以认为是无状态的。

有状态容器stateful

有状态容器应用的特征是应用中处理的历史请求或操作，对现在或未来的操作是有影响的，那历史数据就必须被记录下来，这种应用就被称之为有状态容器应用。最典型的有状态应用莫过于数据库了，当数据库重新拉起时，你当然“要求”之前写入数据库的记录必须能被正确无误地加载出来。其实同样地，很多的消息队列（例如RabbitMQ等），为了不使消息丢失，消息队列中间件也会将消息进行持久化。当然，随着容器应用的边界越发广阔，越来越多的有状态应用正在容器化，我们看到很多的AI、自动驾驶、HPC任务都在进行容器化。

K8S数据卷

为了实现容器部署过程中数据共享和数据持久化的需求，Docker中提供了数据卷，K8S同样也提供了数据卷（volume）的功能，使得容器具有挂载外部存储的能力。

Kubernetes 支持很多类型的卷，比如

  • 本地数据卷：emptyDir，hostPath等
  • 网络数据卷：NFS，Ceph，GlusterFS等
  • 共有云：AWS，EBS等
  • K8S资源：configmap，secret等

卷的核心是一个目录，其中可能存有数据，Pod 中的容器可以访问该目录中的数据。Pod 可以同时使用任意数目的卷类型，使用卷时,需要在 pod.spec.volumes 字段中设置为 Pod 提供的卷，并在 pod.spec.containers.volumeMounts 字段中声明卷在容器中的挂载位置。

数据卷

emptyDir临时卷

emptyDir是一个临时卷，临时卷类型的生命周期与 Pod 相同，在容器重启期间数据都不会丢失，当 Pod 不再存在时，K8S也会销毁临时卷。使用临时卷，多个Pod之间不能共享数据，但是同一个Pod的多个容器是可以实现数据共享的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: pod
  name: pod
spec:
  volumes:
  - name: v1
    emptyDir: {}		# 通常写个"{}"即可，无需为emptyDir指定任何参数
  containers:
  - image: nginx
    name: n1
    volumeMounts:
    - name: v1
      mountPath: /xx
  - image: nginx
    name: s1
    command: ["sh","-c","sleep 1000"]
    volumeMounts:
    - name: v1
      mountPath: /yy

创建上面的Pod，可以看到指定了一个名称为v1的临时卷emptyDir，Pod中有两个容器，挂载了同一个emptyDir，两个容器可以挂载到容器内不同的目录，仍能实现数据共享。

注意：删除pod之后，临时卷会消失，emptyDir卷可以共享数据但是不可以永久存储

hostPath数据卷

hostPath卷将主机节点文件系统上的文件或目录挂载到Pod 中，可以实现同一个Node节点中多个Pod之间的数据共享，删除pod后，主机目录上的文件还是存在的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1
kind: Pod
metadata:
  name: hostpath
spec:
  volumes:
  - name: v1
    hostPath:
      path: /hostdir
  containers:
  - image: nginx
    name: h1
    volumeMounts:
    - name: v1
      mountPath: /xx
      readOnly: true

hostPath除了必需的 path 属性之外，在K8S的1.5版本之后，可以选择性地为 hostPath 卷指定 type。支持的 type 值如下：

type 行为
Directory 在给定路径上必须存在的目录。
DirectoryOrCreate 如果在给定路径上什么都不存在，那么将根据需要创建空目录，权限设置为 0755，具有与 kubelet 相同的组和属主信息。
File 在给定路径上必须存在的文件。
FileOrCreate 如果在给定路径上什么都不存在，那么将在那里根据需要创建空文件，权限设置为 0644，具有与 kubelet 相同的组和所有权。
Socket 在给定路径上必须存在的 UNIX 套接字。
CharDevice 在给定路径上必须存在的字符设备。
BlockDevice 在给定路径上必须存在的块设备。

注意：hostPath 卷存在许多安全风险，最佳做法是尽可能避免使用 hostPath。 当必须使用 hostPath 卷时，它的范围应仅限于所需的文件或目录，并以只读方式挂载。

nfs数据卷

nfs卷能将 NFS (网络文件系统) 挂载到 Pod 中。 既能持久化数据，不会随着Pod的删除而消失，又能实现不同node之间的数据共享。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: v1
kind: Pod
metadata:
  name: nfsshare
spec:
  volumes:
  - name: v1
    nfs:
      server: 192.168.110.133		# nfs服务端的IP地址
      path: /sharedir		# nfs服务端的共享目录
      # readOnly: true 只读
  containers:
  - image: nginx
    name: h1
    volumeMounts:
    - name: v1
      mountPath: /xx

使用nfs数据卷的前提是已有NFS服务端在运行，并且相关目录已经共享，node节点已经安装了nfs-utils。

nfs支持三个参数，在上面的文件中已有体现。

持久卷PV和PVC

PV

简介

PV（persistent volume）是持久化数据卷，一种K8S的全局资源。

持久卷是对存储资源数据卷(volume)创建和使用的抽象，使得存储作为集群中的资源管理。该资源对象本身并不负责数据的真实存储，而是负责和后端存储进行关联，每个pv都有提前定义好的存储能力。

pv对存储资源进行抽象后，可以实现三大特性：

  1. 后端存储的权限管控(rw,ro);
  2. 预先定义存储能力(使用多大的存储空间);
  3. 后端存储卷(volumes)存储类型的应用解耦(无需关心后端用的是NFS、Cephfs或是其他)

在迁移服务时就无需关心集群底层存储使用的资源，而是直接使用pv即可。

pv资源实例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1
kind: PersistentVolume		# 指定pv资源类型
metadata:
  name: pv01
  labels:
    type: ssd
spec:
  capacity:		# 定义PV存储容量的大小
    storage: 10Gi 
  accessModes:		# 指定访问模式
    - ReadWriteMany 
  persistentVolumeReclaimPolicy: Recycle		# 指定PV的回收策略
  nfs:		# 指定PV后端的支持存储设备类型
    path: "/data/kubernetes/pv01"
    server: 172.200.1.101
    readOnly: false

相关属性

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# PV的访问模式accessModes
PV支持的访问模式accessModes有：
-	ReadWriteOnce：卷可以被一个节点以读写方式挂载。简写RWO
-	ReadOnlyMany：卷可以被多个节点以只读方式挂载。简写ROX
-	ReadWriteMany：卷可以被多个节点以读写方式挂载。简写RWX
-	ReadWriteOncePod：卷只能被单个Pod以读写方式挂载。如果你想确保整个集群中只有一个Pod可以读取或写入该 PVC，可以使用这种访问模式。这只支持CSI卷以及需要K8S的1.22以上版本。简写RWOP

# PV的回收策略persistentVolumeReclaimPolicy
当用户不再使用数据卷时，或者PVC被删除，因此PV将从申领中被释放，此时支持三种回收策略：
-	Retain：PV仍然存在，其中的数据还在，需要手动回收，暂时不能被重新申领，处于`realeased`状态，这是默认的策略
-	Recycle：清除PV中的数据，效果相当于执行`rm -rf /data/kubernetes/*`
-	Delete：与PV相连的后端存储同时删除

# PV生命周期
一个PV的生命周期中，可能会处于四种不同的阶段:
-	Available(可用): 表示可用状态，还未被任何PVC绑定。
-	Bound(已绑定): 表示PV已经被PVC绑定。
-	Released(已释放): PVC被删除，但是这种状态下PV是不可重新分配的，需要手动清理保留的数据(因为默认的回收策略是"Retain")。
-	Failed(失败): 表示该PV的自动回收失败。

PVC

简介

PVC（persistent volume claim）是持久化数据卷声明，属于K8S集群某一个namespace的局部资源。

PVC也不负责数据的真实存储，它只是显式声明需要使用的存储资源需求，然后K8S会自动去关联符合条件的pv，从而实现对存储资源的使用。PVC以特定的大小和访问模式来请求关联PV，因此PVC会耗用 PV 资源。

PVC资源示例

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: PersistentVolumeClaim		# 指定资源类型是PVC
metadata:
  name: tomcat-mysql-pvc
spec:
  selector:		# 指定标签选择器
    matchLabels:		# 标签选择器类型为matchLabels
      type: hdd
  accessModes:		# 访问模式
    - ReadWriteMany
  resources:
    requests:		# 指定需要的存储大小
      storage: 35Gi

相关属性

1
2
3
4
5
6
7
# 标签选择器
# 因为PV是一种资源，它是可以指定标签的。上面提到PVC和PV进行关联的方式是需要满足PVC的存储需求，并且访问模式需要相同。除了这两个要求，还有一个标签选择器（selector）可以指定关联的偏好。标签选择器有两种：
-	matchLabels	<object>
    指定一组或多组key/value值，能够满足的PV可以优先匹配
     
-	matchExpressions	<[]Object>
    表达式形式的标签选择器，功能更加高级，自行查阅官方文档，不再赘述。

使用PVC示例

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
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mysql
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: mysql
    spec:
      volumes:
        - name: datadir		# 指定要使用的数据卷的名称
          persistentVolumeClaim:
            claimName: tomcat-mysql-pvc		# 指定PVC的名称，注意要创建的Pod的名称空间中必须存在该PVC
            readOnly: false		# PVC是否只读，默认值就为false，如果想要只读请设置为"true"
      containers:
        - name: mysql
          image: mysql:5.7
          ports:
            - containerPort: 3306
          env:
            - name: MYSQL_ROOT_PASSWORD
              value: '123456'
          volumeMounts:
            - name: datadir		# 指定要挂载的数据卷的名称，必须在上面的volumes中声明过
              mountPath: /var/lib/mysql		# 挂载在容器中的路径
2024-03-30 该篇文章被 邓胖胖 打上标签: K8S 归为分类: 学习笔记