Kubernetes—持久化存储

最新推荐文章于 2024-09-22 15:16:06 发布

_李少侠_

最新推荐文章于 2024-09-22 15:16:06 发布

阅读量329

点赞数

分类专栏：云原生文章标签： kubernetes

本文链接：https://blog.csdn.net/weixin_45804031/article/details/113725684

版权

云原生专栏收录该内容

34 篇文章 5 订阅

订阅专栏

为什么需要持久化存储

在kubernetes的官方文档中，对Pod的生命周期做出了如下解释：

和一个个独立的应用容器一样，Pod 也被认为是相对临时性（而不是长期存在）的实体。 Pod 会被创建、赋予一个唯一的 ID（UID），并被调度到节点，并在终止（根据重启策略）或删除之前一直运行在该节点。

如果一个节点死掉了，调度到该节点的 Pod 也被计划在给定超时期限结束后删除。

Pod 自身不具有自愈能力。如果 Pod 被调度到某节点而该节点之后失效，或者调度操作本身失效，Pod 会被删除；与此类似，Pod 无法在节点资源耗尽或者节点维护期间继续存活。Kubernetes 使用一种高级抽象，称作控制器，来管理这些相对而言可随时丢弃的 Pod 实例。

任何给定的 Pod （由 UID 定义）从不会被“重新调度（rescheduled）”到不同的节点；相反，这一 Pod 可以被一个新的、几乎完全相同的 Pod 替换掉。如果需要，新 Pod 的名字可以不变，但是其 UID 会不同。

如果某物声称其生命期与某 Pod 相同，例如存储卷，这就意味着该对象在此 Pod （UID 亦相同）存在期间也一直存在。如果 Pod 因为任何原因被删除，甚至某完全相同的替代 Pod 被创建时，这个相关的对象（例如这里的卷）也会被删除并重建。

可以看出，假如我们在k8s集群中部署数据库，此时若不进行持久化存储，一旦数据库所在节点出现故障，那么数据库中的数据也会随之永久丢失。

k8s的持久化存储方案

PV和PVC

PV（PersistentVolume）是集群中的一块存储空间，由管理员创建和维护，或者使用Storage Class动态扩展。与节点一样，属于集群资源。与 Volume 相似，生命周期独立于 Pod。

PVC（PersistentVolumeClaim）是用户对存储的请求。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV。

有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。

生命周期

PV是群集中的资源。PVC是对这些资源的请求，并且还充当对资源的检查。PV和PVC之间的相互作用遵循以下生命周期：

供应准备Provisioning：通过集群外的存储系统或者云平台来提供存储持久化支持。
- 静态提供Static：集群管理员创建多个PV。它们携带可供集群用户使用的真实存储的详细信息。它们存在于Kubernetes API中，可用于消费
- 动态提供Dynamic：当管理员创建的静态PV都不匹配用户的PersistentVolumeClaim时，集群可能会尝试为PVC动态配置卷。此配置基于StorageClasses：PVC必须请求一个类，并且管理员必须已创建并配置该类才能进行动态配置。要求该类的声明有效地为自己禁用动态配置。
绑定Binding：用户创建pvc并指定需要的资源和访问模式。在找到可用pv之前，pvc会保持未绑定状态。
使用Using ：Pod资源基于persistentVolumeClaim卷类型的定义、将选择定的PVC关联为存储卷、而后即可为内部的容器所使用、对于支持多种访问模式的存储卷来说、用户需要额外指定要使用的模式
一旦完成将存储卷挂载值Pod对象内的容器中，其应用即可使用关联的PV提供的存储空间
Storage Object in Use Protection：有用户删除了仍处于某pod资源使用中的PVC时，Kubernetes不会立即予以移除、而是推迟到不再被任何pod资源使用后方才执行删除操作
回收Reclaiming：pv可以设置三种回收策略：保留（Retain），回收（Recycle）和删除（Delete）。
- 保留策略：删除PVC之后、kubernetes系统不会自动删除PV，而仅仅是将它置于"释放(releases)状态。此种状态的PV尚且不能被其他PVC申请所绑定，因为此前的申请生成的数据仍然存在，需要由管理员手动决定其后续处理方案。
- 删除策略：对于支持Delete回收策略的存储插件来说、在PVC被删除后会直接移除PV对象、同时移除的还有PV相关的外部存储系统上的存储资产。动态创建的PV资源的回收策略屈居于相关存储类上的定义，存储类上相关的默认策略为delete，大多数情况下，管理元都需要按用户期望的处理机制修改此默认策略，以免导致数据费计划内的误删除。
- 回收策略：如果可被底层存储插件支持，资源回收策略会在存储卷商执行数据删除操作并让PV资源再次变为可被Claim。管理元也可以配制一个自定义的回收器POD模板，以便执行自定义的回收操作。不过，此种回收策略行将废弃。

通过NFS实现持久化存储

服务端安装NFS

服务端ip：192.168.186.198

共享目录： /public

安装NFS和RPC

#安装nfs服务
yum install -y nfs-utils
#安装rpc服务
yum install -y rpcbind

启动服务

systemctl start rpcbind    
systemctl enable rpcbind   
systemctl start nfs-server      
systemctl enable nfs-server

配置共享文件目录

#创建共享目录
mkdir /public
#编辑配置文件,输入 /public 可访问的ip地址
vi /etc/exports
	/public 192.168.186.*

客户端挂载

客户端所在网络：192.168.186.*

客户端目录：/mnt/public

#客户端创建目录
mkdir /mnt/public
#编辑配置文件，挂载目录
vi /etc/fstab
	192.168.186.198:/public /mnt/public nfs defaults 0 0
#使文件生效
mount -a

k8s部署nfs-client

下载配置文件

git clone https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner.git
cd nfs-subdir-external-provisioner/deploy

创建ServiceAccount

NS=$(kubectl config get-contexts|grep -e "^\*" |awk '{print $5}')
NAMESPACE=${NS:-default}
sed -i'' "s/namespace:.*/namespace: $NAMESPACE/g" ../deploy/rbac.yaml ./deployment.yaml
kubectl create -f ./rbac.yaml

部署NFS Provisioner

    #修改deployment.yaml
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs
            - name: NFS_SERVER
              value: 192.168.186.198 #替换为服务端ip
            - name: NFS_PATH
              value: /public #共享目录
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.186.198 #替换为服务端ip
            path: /public #共享目录
            
 
 #创建NFS Provisioner
 kubectl apply -f deployment.yaml