^-^
K8S存储
  1. 概述
  2. PV和PVC
    1. PV
    2. PVC
    3. StorageClass
  3. 本地存储
    1. emptyDir临时卷
    2. hostPath数据卷
    3. Local PV
      1. 延迟绑定
      2. 动态制备Local PV
  4. 网络存储
    1. NFS存储
    2. Ceph存储
    3. 动态制备

概述

在研究K8S存储之前，需要先明确一下有状态容器和无状态容器的概念：

无状态容器stateless

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

有状态容器stateful

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

K8S数据卷

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

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

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

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

PV和PVC

如果要在Pod中直接对接底层存储的各种参数，对于Pod管理来说太费劲了，为了屏蔽底层存储的管理细节，让用户更加方便的使用，k8s提供了两个抽象单位：

  • PV：负责对接底层存储，屏蔽底层不同存储设备的差异
  • PVC：负责对接pv，屏蔽pv的差异

九、Kubernetes之 PV和PVC - yaowx - 博客园

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`状态，暂时不能被其他PVC绑定，其中的数据还在，需要手动回收，这是默认的策略
-	Delete：PV会被删除，与PV相连的后端存储数据同时被删除，除非测试场景不推荐使用
-	Recycle：PV仍然存在，会清除PV中的数据，PV状态重新变为`Available`，可以被其他PVC绑定。（已经被k8s弃用）

# 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
14
apiVersion: v1
kind: PersistentVolumeClaim		# 指定资源类型是PVC
metadata:
  name: tomcat-mysql-pvc
spec:
  storageClassName: manual  # 代表手动创建，也可以使用动态制备的方法，此处要换成具体的StorageClass类名
  selector:		# 指定标签选择器
    matchLabels:		# 标签选择器类型为matchLabels
      type: hdd
  accessModes:		# 访问模式，需要跟PV的访问模式相同
    - ReadWriteMany
  resources:
    requests:		# 指定需要的存储大小
      storage: 35Gi

StorageClass

虽然通过PV和PVC可以满足Pod使用持久存储的需求，但是大规模场景下，手动创建PV过于繁琐。并且由于不同的存储设备性能不同，如果能进行归类的话，也方便Pod的使用。为了解决上面的两个问题，诞生了StorageClass，它允许PVC自动创建PV并与之绑定。

在这里插入图片描述

本地存储

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后，主机目录上的文件还是存在的。

hostPath的优点：直接使用本地磁盘，速度最优

hostPath的缺点：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 卷时，它的范围应仅限于所需的文件或目录，并以只读方式挂载。

Local PV

在hostPath的基础上，k8s依靠pv与pvc实现了一个新特性叫Local PV。

Local PV本质也是在目录主机创建目录，实现的功能类似于hostPath+nodeAffinity，具体细节如下：

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: PersistentVolume
metadata:
  name: pv-local
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  #storageClassName: local-storage		# 后文延迟绑定用到
  local:
    path: /data/k8s/localpv # k8s-node-01节点上的目录，该目录强烈建议挂载一块单独的磁盘
  nodeAffinity: # pod被调度时生效
  required:
    nodeSelectorTerms:
    - matchExpressions:
      - key: kubernetes.io/hostname
        operator: In
        values:
        - k8s-node-01

与普通pv不同的地方：

  1. 定义一个 local 字段，表明它是一个 Local PV，path 字段指定 PV 对应的本地磁盘的路径，即： local /data/k8s/localpv
  2. 添加了一个节点亲和性 nodeAffinity 字段指定 k8s-node-01 这个节点。这样，调度器在调度 Pod 的时候，就能够知道一个 PV 与节点的对应关系，从而做出正确的选择。
  3. 对比普通pod的创建过程，都是先把调度pod到某个节点上，然后再持久化/创建节点上的Volume目录。但对于使用local PV的pod来说，local PV必须事先创建好、存储都需要提前准备好，因为调度器会根据该 pv的nodeAffinity把pod调度到固定的节点上，之后这个Pod每次调度都会被调度到这个节点上，这种情况被称为”卷亲和”。

延迟绑定

Local PV 存在一种情况，当我们在多个节点上都创建了Local PV的时候，我们在创建Pod的时候，该Pod使用的PVC会与其中一个local pv绑定成功，然后该Pod被调度到这个Local PV 所在的节点，而这个节点事先并未经过Pod的调度策略，所以可能会出现资源不足等情况，导致Pod一直处于Pending状态。

为了解决这个问题，可以通过延迟绑定来实现，即让pod的调度器综合考虑资源+pv卷来进行调度，调度完成后，再绑定pvc与 pv，这样才合理。

延迟绑定是通过StorageClass来实现的，通过创建 StorageClass 来指定这个动作，在 StorageClass 中有一个 volumeBindingMode的属性，该属性的值需要配置为WaitForFirstConsumer ，就是告诉 Kubernetes 在发现这个 StorageClass 关联的 PVC 与 PV 可以绑定在一起，但不要现在就立刻执行绑定操作（即：设置 PVC 的 VolumeName 字段），而是要等到第一个声明使用该 PVC 的 Pod 出现在调度器之后，调度器再综合考 虑所有的调度规则，当然也包括每个 PV 所在的节点位置，来统一决定这个 Pod 声明的 PVC到底应该跟哪个 PV 进行绑定。通过这个延迟绑定机制，原本实时发生的 PVC 和 PV 的绑定过程， 就被延迟到了 Pod 第一次调度的时候在调度器中进行，从而保证了这个绑定结果不 会影响 Pod 的正常调度。

创建一个StorageClass资源：

1
2
3
4
5
6
7
# local-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage		# StorageClass类名
provisioner: kubernetes.io/no-provisioner		# no-provisioner代表是手动创建的 PV，不需要动态来生成
volumeBindingMode: WaitForFirstConsumer		# 指定延迟绑定特性

在PVC的yaml文件中指定storageClassName: local-storage即可实现延迟绑定。

动态制备Local PV

由 Rancher 开发的local-path-provisioner，这个存储方案允许 Kubernetes 用户在每个节点上使用Local PV ，只需要在PVC中指定其对外提供的storageclass默认名local-path即可，实现自动创建PV和延迟绑定。

下载地址：local-path-storage.yaml，注意镜像可能无法拉取，需要替换。

在使用 local-path-provisioner 时，由于它会在创建 PV 时将 PV 与创建它的节点绑定，因此 Kubernetes 调度器会自动将使用该 PV 的 Pod 调度到能够访问该 PV 的节点。这 意味着即使你没有配置 nodeAffinity，Pod 也会被调度到与 PV 绑定的节点上，以确保它能够访问存储卷。

注意：deployment中正常使用PVC即可，statefulset中有所不同，需要在Pod模板中指定volumeClaimTemplates：

1
2
3
4
5
6
7
8
9
volumeClaimTemplates:
- metadata:
    name: redis-data
  spec:
    accessModes: [ "ReadWriteOnce" ]  # 注意：local-path 只支持 ReadWriteOnce 和 ReadWriteOncePod
    storageClassName: "local-path"
    resources:
      requests:
        storage: 1Gi

网络存储

对速度有特殊要求的的场景（多为有状态服务）会用到本地存储，你需要付出的代价就是pod无法随意漂移，如果对速度没有极致的要求、想实现pod可以随意漂移，那就不能用本地存储了，需要用到网络存储， 网络存储里最简单的就属NFS了

NFS存储

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

示例yaml文件如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: PersistentVolume
metadata:
  name: inroad-pv
  labels:
    pv-name: inroad-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /02735419a2a5/inroad
    server: 10.100.3.132
  persistentVolumeReclaimPolicy: Retain

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

Ceph存储

ceph是一种分布式存储系统，支持对象存储，块存储和文件系统存储，本次仅给出文件系统存储的示例PV文件。

  1. 在ceph存储系统已经准备好的状态下，每台Node节点的hosts文件都要具备如下内容：

    1
    2
    3
    4
    5
    10.100.11.165 ceph-admin1
    10.100.11.180 ceph-mon2
    10.100.11.181 ceph-mon1
    10.100.11.185 ceph-mon3
    10.100.11.186  ceph-mon4

  2. 在ceph存储系统已经准备好的状态下，先测试一下手动挂载ceph存储命令

    1
    mount -t ceph ceph-mon1:/ /mnt/ -o name=admin,secret=AQB5HWFnbIDhBRAAnnbftLbQObfQWvZ9X7te2A==

  3. 测试没问题之后，在k8s集群中创建一个secret资源，用于访问ceph存储

    1
    2
    3
    4
    5
    6
    7
    8
    9
    # ceph-secret.yml文件
    apiVersion: v1
    kind: Secret
    metadata:
      name: ceph-secret
      namespace: default
    type: "kubernetes.io/cephfs"
    data:
      key: QVFCNUhXRm5iSURoQlJBQW5uYmZ0TGJRT2JmUVd2WjlYN3RlMkE9PQo=

    注意：ceph-secret.yml文件中使用的key是由手动挂载命令中的secret通过base64加密的

  4. 示例pv文件

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: qyhdhg-pv
      labels:
        pv-name: qyhdhg-pv
    spec:
      capacity:
        storage: 1Gi
      accessModes:
      - ReadWriteMany
      persistentVolumeReclaimPolicy: Retain
      cephfs:
        monitors:
        - 10.100.11.165
        - 10.100.11.180
        - 10.100.11.181
        - 10.100.11.185
        - 10.100.11.186
        path: QYHDHG
        user: admin
        secretRef:
          name: ceph-secret
          namespace: default

动态制备

网络存储也可以动态制备PV，此处以最简单的NFS为例

参考 nfs provisioner，使用helm方式部署

注意：根据需要修改values.yaml文件中的defaultClass，这代表是否把此StorageClass作为默认的存储类。另外建议把reclaimPolicy设置为Retain

2024-12-26 该篇文章被 邓胖胖 打上标签: K8S 归为分类: 学习笔记