云原生（二十六） | Kubernetes 篇之 Kubernetes（k8s）持久化

作者：Lansonli

2022 年 8 月 26 日
广东
本文字数：2005 字
阅读完需：约 7 分钟

Kubernetes（k8s）持久化

一、VOLUME

1、基础

Kubernetes 支持很多类型的卷。Pod 可以同时使用任意数目的卷类型
临时卷类型的生命周期与 Pod 相同，但持久卷可以比 Pod 的存活期长
当 Pod 不再存在时，Kubernetes 也会销毁临时卷；
Kubernetes 不会销毁持久卷。
对于给定 Pod 中任何类型的卷，在容器重启期间数据都不会丢失。
使用卷时, 在 .spec.volumes 字段中设置为 Pod 提供的卷，并在 .spec.containers[*].volumeMounts 字段中声明卷在容器中的挂载位置。

2、使用 subPath

有时，在单个 Pod 中共享卷以供多方使用是很有用的。 volumeMounts.subPath 属性可用于指定所引用的卷内的子路径，而不是其根路径。

3、使用 NFS

3.1、安装 NFS

# 在任意机器yum install -y nfs-utils#执行命令 vi /etc/exports，创建 exports 文件，文件内容如下：echo "/nfs/data/ *(insecure,rw,sync,no_root_squash)" > /etc/exports#/nfs/data  172.26.248.0/20(rw,no_root_squash)
# 执行以下命令，启动 nfs 服务;创建共享目录mkdir -p /nfs/datasystemctl enable rpcbindsystemctl enable nfs-serversystemctl start rpcbindsystemctl start nfs-serverexportfs -r#检查配置是否生效exportfs# 输出结果如下所示/nfs/data /nfs/data

复制代码

3.2、VOLUME 进行挂载测试

#测试Pod直接挂载NFS了apiVersion: v1kind: Podmetadata:  name: vol-nfs  namespace: defaultspec:  containers:  - name: myapp    image: nginx    volumeMounts:    - name: html      mountPath: /usr/share/nginx/html/  volumes:  - name: html    nfs:      path: /nfs/data   #1000G      server: 自己的nfs服务器地址

复制代码

3.3、扩展-NFS 文件同步

#服务器端防火墙开放111、662、875、892、2049的 tcp / udp 允许，否则远端客户无法连接。#安装客户端工具yum install -y nfs-utils

#执行以下命令检查 nfs 服务器端是否有设置共享目录# showmount -e $(nfs服务器的IP)showmount -e 172.26.165.243# 输出结果如下所示Export list for 172.26.165.243/nfs/data *
#执行以下命令挂载 nfs 服务器上的共享目录到本机路径 /root/nfsmountmkdir /root/nfsmount# mount -t nfs $(nfs服务器的IP):/root/nfs_root /root/nfsmount#高可用备份的方式mount -t nfs 172.26.165.243:/nfs/data /root/nfsmount# 写入一个测试文件echo "hello nfs server" > /root/nfsmount/test.txt
#在 nfs 服务器上执行以下命令，验证文件写入成功cat /root/nfsmount/test.txt

复制代码

二、PV&PVC&StorageClass

1、基础概念

存储的管理是一个与计算实例的管理完全不同的问题。
PersistentVolume 子系统为用户和管理员提供了一组 API，将存储如何供应的细节从其如何被使用中抽象出来。
为了实现这点，我们引入了两个新的 API 资源：PersistentVolume 和 PersistentVolumeClaim。

持久卷（PersistentVolume ）：

持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者使用存储类（Storage Class）来动态供应。
持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样，也是使用卷插件来实现的，只是它们拥有独立于使用他们的 Pod 的生命周期。
此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。

持久卷申请（PersistentVolumeClaim，PVC）：

表达的是用户对存储的请求
概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。
Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式（例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一来挂载，参见访问模式）。

存储类（Storage Class）:

尽管 PersistentVolumeClaim 允许用户消耗抽象的存储资源，常见的情况是针对不同的问题用户需要的是具有不同属性（如，性能）的 PersistentVolume 卷。
集群管理员需要能够提供不同性质的 PersistentVolume，并且这些 PV 卷之间的差别不仅限于卷大小和访问模式，同时又不能将卷是如何实现的这些细节暴露给用户。
为了满足这类需求，就有了 存储类（StorageClass） 资源。