【云原生】Kubernetes之持久化

Kubernetes 持久化存储

文章目录

Kubernetes 持久化存储
- 一、为什么要做持久化存储
- 二、都有哪些存储
- - 2.1、emptyDir
  - - 2.1.1、什么是emptyDir
    - 2.1.2、emptyDir作用
    - 2.1.3、emptyDir的应用场景
    - 2.1.4、emptyDir优缺点
    - 2.1.5、emptyDir的使用方式
  - 2.2、hostPath
  - - 2.2.1、什么是hostPath
    - 2.2.2、hostPath应用场景
    - 2.2.3、hostPath优缺点
    - 2.2.4、hostPath的使用方式
  - 2.3、PV以及PVC
  - - 2.3.1、什么是PV
    - 2.3.2、什么是PVC
    - 2.3.3、PV的供应方式
    - 2.3.4、绑定
    - 2.3.5、使用流程
    - 2.3.6、回收策略
    - 2.3.7、访问模式
    - 2.3.8 示例
    - - 2.3.8.1、资源列表
      - 2.3.8.2、部署NFS
      - 2.3.8.2.1、关闭防火墙
        2.3.8.2.2、关闭内核安全机制
        2.3.8.2.3、安装
      - 2.3.8.3、PV、PVC应用示例

一、为什么要做持久化存储

在k8s中部署的应用都是以Pod容器的形式运行的，假如我们部署的MySQL、Redis等数据库，需要对这些数据库产生的数据做备份。因为Pod是有生命周期的，如果Pod不挂在数据卷，那Pod删除或重启后这些数据会随之消失，如果想要长久的保留这些数据就要用到Pod数据持久化存储。

二、都有哪些存储

2.1、emptyDir

2.1.1、什么是emptyDir

emptyDir是一个临时存储卷，与Pod的声明周期绑定在一起，如果Pod被删除了，这意味着数据也被随之删除。

2.1.2、emptyDir作用

可以实现持久化
同一个Pod的多个容器可以实现数据共享，多个不同的Pod之间不能进行数据通信
随着Pod的生命周期而存在，当我们删除Pod时，其数据也会被随之删除

2.1.3、emptyDir的应用场景

临时缓存空间，比如基于磁盘的归并排序
为较耗时计算任务提供检查点，以便任务能方便的从崩溃前状态恢复执行
存储Web访问日志及错误日志等信息

2.1.4、emptyDir优缺点

优点

可以实现同一个Pod内多个容器之间数据共享
当Pod内的某个容器被强制删除时，数据并不会丢失，因为Pod没有删除

缺点

当Pod被删除时，数据也会随之删除
不同的Pod之间无法实现数据共享

2.1.5、emptyDir的使用方式

[root@master ~]# cat emptyDir.yaml 
apiVersion: v1
kind: Pod
metadata:name: test
spec:containers:- name: test-podimage: busybox:1.28imagePullPolicy: IfNotPresent# 定义容器内的挂载点volumeMounts:# 挂载的卷名称未data- name: data# 将data数据卷挂载到内容内部的/opt目录下mountPath: /opt/command: ["sh","-c","sleep 1000"]# 创建一个卷volumes:# 卷名字叫data，刚好与容器挂载的卷名字一致- name: data# emptyDir是一个空目录，用于临时存储数据。{}表示使用默认配置emptyDir: {}

# 查看临时目录存在的位置，可用如下方法
[root@master ~]# kubectl get pod -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP           NODE    NOMINATED NODE   READINESS GATES
test   1/1     Running   0          32s   10.244.2.2   node1   <none>           <none># 查看 Pod 的 uid，指定的机器指定目录下会生成带有 uid 号的目录
[root@master ~]# kubectl get pod test -o yaml | grep uiduid: b6b8a98d-9324-4869-a443-4e7dbe24f232# 登录 node1 机器
[root@node1 ~]# tree /var/lib/kubelet/pods/b6b8a98d-9324-4869-a443-4e7dbe24f232/
/var/lib/kubelet/pods/b6b8a98d-9324-4869-a443-4e7dbe24f232/
├── containers
│   └── test-pod
│       └── 2e82889a
├── etc-hosts
├── plugins
│   └── kubernetes.io~empty-dir
│       ├── data
│       │   └── ready
│       └── wrapped_kube-api-access-n7cgv
│           └── ready
└── volumes├── kubernetes.io~empty-dir│   └── data└── kubernetes.io~projected└── kube-api-access-n7cgv├── ca.crt -> ..data/ca.crt├── namespace -> ..data/namespace└── token -> ..data/token11 directories, 7 files

# 在容器里面写文件，对应的emptyDir目录会有相应文件
[root@master ~]# kubectl exec -it test -- sh -c 'date > /opt/time.txt'
[root@master ~]# kubectl exec -it test -- ls /opt/time.txt
/opt/time.txt
[root@master ~]# kubectl exec -it test -- cat /opt/time.txt
Fri Jul  5 00:25:52 UTC 2024# 登录到node1机器查看
[root@node1 ~]# cat /var/lib/kubelet/pods/b6b8a98d-9324-4869-a443-4e7dbe24f232/volumes/kubernetes.io~empty-dir/data/time.txt 
Fri Jul  5 00:25:52 UTC 2024

2.2、hostPath

2.2.1、什么是hostPath

hostPath Volume是指Pod挂载宿主机上的目录或文件。hostPath Volume使得容器可以使用宿主机的文件系统进行存储，hostpath（宿主机路径）：节点级别的存储卷，在Pod被删除，这个存储卷还是存在的，不会被删除，所以只要同一个Pod被调度到同一个节点上来，在Pod被删除重新被调度到这个节点之后，对应的数据依然存在的

2.2.2、hostPath应用场景

Pod中容器想要访问宿主机文件

2.2.3、hostPath优缺点

优点

可以实现同一个Pod不同容器之间的数据共享
可以实现同一个Node节点不同Pod之间的数据共享

缺点

无法满足跨节点Pod之间的数据共享

2.2.4、hostPath的使用方式

[root@master ~]# cat hostPath.yaml 
apiVersion: v1
kind: Pod
metadata:name: test
spec:containers:- name: test-podimage: busybox:1.28imagePullPolicy: IfNotPresent# 定义容器内部的挂载点volumeMounts:# 挂载卷的名字叫 data- name: data# 叫 data 卷挂载到容器中/optmountPath: /opt# 容器执行的命令，主要是让容器运行command: ["sh","-c","sleep 1000"]# 定义了Pod中挂载的卷volumes:# 卷的名称- name: data# 指定宿主机的卷存储路径hostPath: # 宿主机上的路径，这个Pod被分配到什么Node节点，那么就会自动在该Node节点/下面创建data目录path: "/data"# 卷类型，意味着如果宿主机上/data目录不存在Kubernetes会自动创建它type: DirectoryOrCreate

# 在容器当中写入数据，对应Node节点/data目录下就会出现数据，最终实现持久化存储
[root@master ~]# kubectl exec -it test -- sh -c 'date > /opt/time.txt'
[root@master ~]# kubectl exec -it test -- cat /opt/time.txt
Fri Jul  5 00:39:34 UTC 2024
[root@master ~]# kubectl get pod -o wide
NAME   READY   STATUS    RESTARTS   AGE     IP           NODE    NOMINATED NODE   READINESS GATES
test   1/1     Running   0          5m54s   10.244.1.4   node2   <none>           <none># 登录 node2 机器查看
[root@node2 ~]# ls /data/
time.txt
[root@node2 ~]# cat /data/time.txt 
Fri Jul  5 00:39:34 UTC 2024

2.3、PV以及PVC

前面和大家一起学习了一些基本的资源对象的使用方法，前面我们也和大家降到了有状态的应用和数据有持久化的应用，我们有通过hostPath 或者 emptyDir的方式来持久化我们的数据，但是显然我们还需要更加可靠的存储保存应用持久化数据，这样的容器在重建后，依赖可以使用之前的数据。但是显然存储资源和CPU资源以及内存资源有很多大不同，为了屏蔽底层的技术实现细节，让用户更加方便的使用，Kubernetes便引入了PV和PVC两个重要的资源对象来实现对存储的管理。这也是我们这节课和大家讲解的核心：PV 和 PVC

2.3.1、什么是PV

PV的全称是：PersistentVolume（持久化卷），是对底层的共享存储的一种抽象，PV由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如Ceph、GlusterFS、NFS等，都是通过插件机制完成与共享存储的对接。
PersistentVolume（PV）是集群中的一块存储，由管理员配置或使用存储类动态配置。它是集群中的资源，就像Pod是K8S集群资源一样。PV是容量插件，入Volumes，其声明周期独立于使用PV的任务单个Pod

2.3.2、什么是PVC

PersistentVolumeClaim（PVC）是一个持久化存储卷，我们在创建Pod时可以定义这个类型的存储卷。它类似于一个Pod。Pod消耗节点的资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。pvc在申请pv的时候也可以请求特定大小和访问模式（例如，可以依次读写或多次只读）

2.3.3、PV的供应方式

可以通过两种方式配置PV：静态或动态

静态的：

集群管理员创建了许多PV，它们包含可供集群用户使用的实际存储的详细信息。它们存在于Kubernetes API中，可供使用

动态的：

当管理员创建PV都不匹配用户的PersistentVolumeClaim（PVC）时，集群可能会尝试为PVC专门动态配置卷。此配置基于StorageClasses，PVC必须请求存储类，管理员必须创建并配置该类，以便进行动态配置。

2.3.4、绑定

用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前，pvc会保持未绑定状态
每个持久卷会处于以下阶段（Phase）之一：

Available

卷是一个空闲资源，尚未绑定到任何申领

Bound

该卷已经绑定到某申领

Released

所绑定的申领已被删除，但是关联存储资源尚未被集群回收

Failed

卷的自动回收操作失败

2.3.5、使用流程

需要主调一个存储服务器，把它划分成多个存储空间
K8S管理员可以把这些存储空间定义成多个PV
在Pod中使用PVC类型的存储卷之前需要先创建PVC，通过定义需要使用的PV的大小和对应的访问模式，找到合适的PV
PVC被创建之后，就可以当成存储卷来使用了，我们在定义Pod时就可以使用这个PVC的存储卷
PVC和PV它们时一一对应的关系，PV如果被PVC绑定了，就不能被其他PVC使用了
我们在创建PVC的时候，应该确保和底下的PV能绑定，如果没有合适的PV，那么PVC就会处于pending（等待）状态

2.3.6、回收策略

我们创建Pod时如果使用PVC做为存储卷，那么它会和PV绑定，当删除Pod，PVC和PV绑定就会解除，解除之后和PVC绑定的PV卷里的数据需要怎么处理，目前，卷可以保留，回收或删除：

Retain

当删除PVC的时候，PV仍然存在，处于released状态，但是它不能被其他PVC绑定使用，里面的数据还是存在的，当我们下次再使用的时候，数据还是存在的，这个是默认的回收策略

Recycle 简单擦除（rm -rf /thevolume/*）

Delete

删除PVC时即会从Kubernetes中移除PV，也会从相关的外部设施中删除存储资产

2.3.7、访问模式

PersistentVolume（PV）卷可以用资源提供者所支持的任何方式挂载到宿主系统上。如下表所示，提供者（驱动）的能力不同，每个PV卷的访问模式都会设置为对应卷所支持的模式值。例如，NFS可以支持多个读写客户，但是某个特定的NFS PV卷可能在服务器上以只读的方式导出。每个PV卷都会获得自身的访问模式集合，描述的是特定PV卷的能力
访问模式有：

ReadWriteOnce

卷可以被一个节点以读写方式挂载。ReadWriteOnce访问模式也允许运行在同一节点上的多个Pod访问卷

ReadOnlyMant

卷可以被多个节点以只读方式挂载

ReadWriteMany

卷可以被多个节点以读写方式挂载

ReadWriteOncePod

特性状态：Kubernetes v1.27[beat]

卷可以被单个Pod以读写方式挂载。如果你想确保整个集群中只有一个Pod可以读取或写入该PVC，请使用 ReadWriteOncePod访问模式。这只支持CSI卷以及需要kubernetes 1.22以上版本

在命令行接口（CLI）中，访问模式也使用以下缩写形式：

RWO -ReadWriteOnce
ROX -ReadOnlyMany
RWX -ReadWriteMany
RWOP -ReadWriteOncePod

2.3.8 示例

这里面为了方便演示，决定使用相对简单的NFS这种存储资源

2.3.8.1、资源列表

这里面Kubernetes集群由Master、Node1、Node2节点组成，本节课不在演示Kubernetes的部署了，只解释NFS的部署，以及配置PV、PVC相关内容

操作系统	主机名	配置	IP
CentOS 7.9	master	2C4G	192.168.93.101
CentOS 7.9	node1	2C4G	192.168.93.102
CentOS 7.9	node2	2C4G	192.168.93.103
CentOS 7.9	nfs	2C4G	192.168.93.104

2.3.8.2、部署NFS

NFS节点操作

2.3.8.2.1、关闭防火墙

systemctl stop firewalld
systemctl disable firewalld

2.3.8.2.2、关闭内核安全机制

setenforce 0
sed -i "s/.*SELINUX=.*/SELINUX=disabled/g" /etc/selinux/config

2.3.8.2.3、安装

[root@nfs ~]# yum -y install nfs-utils rpcbind
[root@nfs ~]# mkdir -p /data/volumes
[root@nfs ~]# cat > /etc/exports << EOF
/data/volumes 192.168.93.0/24(rw,no_root_squash)
EOF
[root@nfs ~]# systemctl enable nfs --now

# 所有Kubernetes集群中的节点需要安装以下软件包用以支持NFS
yum -y install nfs-utils rpcbind

2.3.8.3、PV、PVC应用示例

该yaml文件一共创建了3个资源，分别是PV、PVC、Pod
启动PV的名字叫test-pv，指定的存储大小是1G（从NFS的/data/volumes分配的空间），回收策略是Delete，访问模式是ReadWriteMany
PVC叫test-pvc，请求的存储是1G，访问模式是ReadWriteMany
Pod挂载test-pvc这个PVC到/opt目录

[root@master ~]# cat pv-pvc-test.yaml 
apiVersion: v1
# 定义资源对象（PV）
kind: PersistentVolume
metadata:
# PV的名字name: test-pv
spec:
# 定义持久卷的存储容量，这里是1Gcapacity:storage: 1G# 定义回收策略persistentVolumeReclaimPolicy: Delete# 定义访问模式accessModes: ["ReadWriteMany"]# 指定持久卷的后端存储是NFSnfs:# NFS服务器上的路径path: /data/volumes# NFS服务器的IP地址server: 192.168.93.104
---
apiVersion: v1
# 定义资源对象（PVC）
kind: PersistentVolumeClaim
metadata:
# PVC的名字name: test-pvc
spec:# ReadWriteMany表示PVC期望的访问模式与PV匹配accessModes: ["ReadWriteMany"]# 定义PVC所需的存储资源resources:# PVC请求的最小存储容量requests:storage: 1G# PVC促成农户资源上限（不能超过1G）limits:storage: 1G
---
apiVersion: v1
kind: Pod
metadata:name: test
spec:containers:- name: test-podimage: busybox:1.28imagePullPolicy: IfNotPresentvolumeMounts:- name: datamountPath: /optcommand: ["sh","-c","sleep 1000"]volumes:# 定义存储卷的名字- name: datapersistentVolumeClaim:# claimName：test-pvc表明这个卷使用名为test-pvc的持久化声明claimName: test-pvc

[root@master ~]# kubectl apply -f pv-pvc-test.yaml 
persistentvolume/test-pv created
persistentvolumeclaim/test-pvc created
pod/test created

# 查看Pod
[root@master ~]# kubectl get pod
NAME   READY   STATUS    RESTARTS   AGE
test   1/1     Running   0          15s# 查看PVC
[root@master ~]# kubectl get pvc
NAME       STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-pvc   Bound    test-pv   1G         RWX                           27s# 查看PV
[root@master ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS   REASON   AGE
test-pv   1G         RWX            Delete           Bound    default/test-pvc                           56s

# 查看PVC相关信息
[root@master ~]# kubectl describe pvc test-pvc
Name:          test-pvc
Namespace:     default
StorageClass:  
Status:        Bound
Volume:        test-pv
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yespv.kubernetes.io/bound-by-controller: yes
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      1G
Access Modes:  RWX
VolumeMode:    Filesystem
Used By:       test
Events:        <none># 查看PV相关信息
[root@master ~]# kubectl describe pvc test-pv
Name:          test-pvc
Namespace:     default
StorageClass:  
Status:        Bound
Volume:        test-pv
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yespv.kubernetes.io/bound-by-controller: yes
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      1G
Access Modes:  RWX
VolumeMode:    Filesystem
Used By:       test
Events:        <none>

# 写入数据进行验证
[root@master ~]# kubectl exec -it test -- sh -c 'date > /opt/time.txt'[root@master ~]# kubectl exec -it test -- cat /opt/time.txt
Fri Jul  5 01:55:08 UTC 2024

# 查看Pod被被配到那个node节点上
[root@master ~]# kubectl get pod -o wide
NAME   READY   STATUS    RESTARTS   AGE    IP           NODE    NOMINATED NODE   READINESS GATES
test   1/1     Running   0          4m3s   10.244.1.5   node2   <none>           <none># 登录到node2
[root@nfs ~]# cat /data/volumes/time.txt 
Fri Jul  5 01:55:08 UTC 2024