K8S的持久化存储


一、持久化存储

在Kubernetes (K8s) 中,持久化存储是一个重要的概念,它允许容器化应用程序在 Pod 重启或重新调度时保留数据。

使用存储卷,需要如下步骤:
1、定义 pod 的 volume,这个 volume 指明它要关联到哪个存储上的。
volumes:
- mountPath: PATH
name: NAME
2、在容器中要使用 volumemounts 挂载对应的存储。
volumeMounts:
- mountPath: PATH
name: PATH_NAME

emptyDir

emptyDir 是 Kubernetes 中的一种基本卷类型,它为 Pod 中的容器提供了临时存储空间。

生命周期:

  • emptyDir 卷的生命周期与 Pod 相同。
  • 当 Pod 被分配到节点时创建,当 Pod 从节点上移除时删除。

作用:

  • 临时文件存储
  • 计算过程中的中间数据
  • 容器间共享的临时数据
  • 作为应用程序的缓存

可以通过默认截止指定大小限制,来限制 emptyDir 卷的存储容量。来防止占满整个磁盘应用。

实际操作

apiVersion: v1
kind: Pod  
metadata:  
  name: nginx
spec:
  containers:
  - name: nginx
    image: harbor.hiuiu.com/nginx/nginx:1.21.5
    ports:
    - containerPort: 80
    volumeMounts:
    - mountPath: /cache# 指定容器中的目录。
      name: cache-volume
  volumes:
  - name: cache-volume#创建一个cache-volume的卷
    emptyDir:
      sizeLimit: 500Mi

验证过程:
找到pod相对应的node节点,并找出uid,去相对应的节点找到这个文件夹。

kubectl get pod nginx -o yaml |grep uid
kubectl get pod -o wide

在这里插入图片描述

kubectl exec -it -n <namespace> <pod-name> -c <container-name> -- /bin/bash
进入容器内部,然后验证结果。

容器内部:
在这里插入图片描述
对应的pod上:
在这里插入图片描述
缺点:

hostPath

hostPath 是 Kubernetes 中的一种卷类型,它允许将主机节点的文件系统上的文件或目录挂载到 Pod 中。以下是关于 hostPath 的重要概念和特性:

  1. 功能:

    • 允许 Pod 访问主机文件系统。
    • 可以挂载单个文件或整个目录。
  2. 持久性:

    • 数据持久存在于主机上,即使 Pod 被删除。
  3. 使用场景:

    • 访问主机系统文件。
    • 在容器中运行需要访问 Docker 内部的应用。

建立过程

apiVersion: apps/v1
kind: Deployment  
metadata:  
  name: nginx-deployment
  labels:
    app: nginx-dep
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: harbor.hiuiu.com/nginx/nginx:1.22a
        ports:
        - containerPort: 80 #以上是用deployment建立pod
        volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: nginx-volume
      volumes:
      - name: nginx-volume
        hostPath:
          path: /data/webs
          type: DirectoryOrCreate#type的值有不同的
---
apiVersion: v1
kind: Service
metadata:
  name: my-nodeport
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30007
#建立service,可以通过外网访问

将这些 hostPath 的类型:

  1. DirectoryOrCreate
    • 如果路径不存在,创建一个空目录
    • 权限设置为 0755
    • 与 kubelet 具有相同的组和属主信息
  2. Directory
    • 在指定路径上必须已存在目录
  3. FileOrCreate
    • 如果路径不存在,创建一个空文件
    • 权限设置为 0644
    • 与 kubelet 具有相同的组和所有权
  4. File
    • 在指定路径上必须已存在文件
  5. Socket
    • 在指定路径上必须存在 UNIX 套接字
  6. CharDevice (仅限 Linux 节点)
    • 在指定路径上必须存在字符设备
  7. BlockDevice (仅限 Linux 节点)
    • 在指定路径上必须存在块设备

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在不同的节点上,不同的pod会有不同的效果。这是因为挂载的文件内容是不一样的。

NFS存储

在 Kubernetes 中,NFS(Network File System)是一种用于共享存储的卷类型,可以在多个 Pod 之间共享持久化数据。使用 NFS 卷允许不同节点上的 Pod 访问同一存储空间,适合需要共享文件存储的应用场景。以下是关于 Kubernetes 中 NFS 存储的关键点:

NFS 存储的优点

  1. 共享访问

    • 多个 Pod 可以同时访问同一个 NFS 卷,实现数据共享。
  2. 持久性

    • 数据存储在 NFS 服务器上,与 Pod 的生命周期独立,这样即使 Pod 被删除,数据也会被保留。
  3. 可移植性

    • 可以在不同节点和 Pod 之间轻松移动和共享数据。
  4. 分离存储和计算

    • 存储和计算可以分别扩展,从而优化资源使用。
  5. 集中管理

    • 简化了对存储的管理,可以在集中式文件系统中进行备份和恢复。

NFS 存储的缺点

  1. 性能

    • 相较于本地存储,网络传输可能会导致较高的延迟。
    • 性能可能受到网络带宽和 NFS 服务器性能的限制。
  2. 可用性依赖

    • NFS 服务器成为数据访问的单点故障,需确保其高可用性。
  3. 安全性

    • 需要配置适当的权限和网络策略以防止未经授权的访问。
  4. 复杂的设置

    • 需要在 Kubernetes 外部配置和维护 NFS 服务器。

具体操作

apt install nfs-kernel-server
vim /etc/exports
/data/disk *(rw,sync,no_root_squash,no_subtree_check)

代表的含义:

  • /data/disk:

    • 这是你在 NFS 服务器上导出的目录路径。客户端将能够通过 NFS 挂载并访问此目录。
  • *:

    • 代表允许所有主机访问该导出。通常在生产环境中,为了安全起见,这一部分会被限定为特定的主机或域名,例如 192.168.1.0/24 或者 *.example.com
  • rw:

    • Read/Write,允许客户端对该导出的目录进行读和写操作。
  • sync:

    • 规定 NFS 服务器在响应前,将所有数据写入磁盘。这确保了数据的持久性,即使服务器意外崩溃后,数据不易丢失。sync 选项较 async 有更好的数据完整性,但可能会稍微影响性能,因为需要等待数据实际写入磁盘。
  • no_root_squash:

    • 默认情况下,NFS 会将客户端的 root 用户请求映射为匿名用户,这被称为 root_squash,防止远程 root 用户在服务器上拥有 root 权限。而 no_root_squash 则取消这个映射,允许客户端的 root 用户对导出的文件和目录具有 root 权限。这一选项在某些情况下可能造成安全漏洞,因为它允许更高特权的访问。
  • no_subtree_check:

    • 禁用子树检查。这一选项用于提升性能。默认情况下,NFS 会检查客户端请求是否属于导出文件系统中的子树。然而,如果导出目录不是文件系统的根目录,检查会增加开销。禁用此选项可以减少这种开销。
exportfs -arv
刷新/etc/exports文件
apiVersion: v1
kind: Pod  
metadata:  
  name: nginx
spec:
  containers:
  - name: nginx
    image: harbor.hiuiu.com/nginx/nginx:1.21.5
    ports:
    - containerPort: 80
    volumeMounts:
    - mountPath: /usr/share/nginx/html#镜像共享的地址
      name: nginx-volume
  volumes:
  - name: nginx-volume
    nfs:
      server: 192.168.232.100#nfs服务器的地址
      path: /data/disk#本机的地址
      readOnly: false#是否是只读

验证:
进入集群,添加index.html文件。

在这里插入图片描述
挂载的文件夹中也会出现index.html。
在这里插入图片描述

pv和pvc

在 Kubernetes 中,持久存储由 Persistent Volume (PV) 和 Persistent Volume Claim (PVC) 负责管理。它们的设计使得存储与工作负载解耦,实现存储资源的动态管理和高效利用。以下是它们的详细解释以及在实际应用中的使用场景。

Persistent Volume (PV)

Persistent Volume 是一个独立于 Pod 生命周期的存储抽象。PV 是集群中具体存储的表示,由管理员管理和配置。PV 可以在多种存储后端上实现,如本地磁盘、NFS、云提供商的存储服务等。

PV 定义了:

  • 存储容量(如 1Gi)
  • 访问模式(如 ReadWriteOnce、ReadOnlyMany、ReadWriteMany)
  • 存储后端类型和具体配置(如 NFS 服务器地址和路径)
使用场景
  • 企业数据存储:例如,将重要的数据库持久化,将数据库数据文件存储在一个 PV 上,确保即便 Pod 停止或迁移,数据都不会丢失。
  • 共享存储使用:多个应用可以共享相同的持久化数据源,例如多个应用共享一个内容管理系统(CMS)的静态内容。

Persistent Volume Claim (PVC)

PVC 是用户对存储的一种请求。PVC 代表某种存储需求,如需要一个持久化的存储卷,指定的存储大小和访问模式等。PVC 将业务需求与具体存储实现分离,使得开发者无需关心底层存储的细节。

PVC 发出请求后,Kubernetes 会自动寻找满足条件的 PV 并进行绑定。
PVC 定义了:

  • 所需存储大小(如 1Gi)
  • 访问模式(需与所请求的 PV 兼容)
使用场景
  • Pod 持久化存储:对于需要持久化存储空间的应用,Pod 可以通过 PVC 使用后台的 PV,PVC 确保应用所需存储资源存续及可用。
  • 动态存储供给:通过 StorageClass 和 PVC,Kubernetes 可以自动为 PVC 创建和销毁 PV,实现存储的动态供给。

使用 PV 和 PVC 的场景

  1. 静态存储:管理员提前配置好 PV,对应于实际的存储资源。用户创建 PVC 时,这些 PVC 自主找到可用的 PV 并进行绑定,实现静态资源利用。
  2. 动态存储:通过 StorageClass,PVC 可以请求动态供应的存储。Kubernetes 使用 StorageClass 来自动化地为 PVC 创建相应的 PV。这样,存储资源在需要时动态创建,减少了管理员的工作量。
  3. 跨集群存储:通过 PV 和 PVC 的结合,可以实现多集群间共享底层存储资源,用于灾备和跨集群高可用设计。
    总结来说,PV 和 PVC 是 Kubernetes 世界中强大而灵活的持久化存储管理方式,降低了深度存储系统管理的复杂性,提供了与工作负载分离的资源管理方式,使得开发和运维能够更专注于应用本身的开发与交付。

实际操作

创建顺序:pv>pvc>pod
删除顺序:pod>pvc>pv

(1)准备存储服务

mkdir /data/disk/v{1,2,3,4,5} -p
vim /etc/exports
/data/disk/v1 *(rw,sync,no_root_squash)
/data/disk/v2 *(rw,sync,no_root_squash)
/data/disk/v3 *(rw,sync,no_root_squash)
/data/disk/v4 *(rw,sync,no_root_squash)
/data/disk/v5 *(rw,sync,no_root_squash)

(2)建立pv

apiVersion: v1  
kind: PersistentVolume  
metadata:  
  name: v1  
spec:  
  capacity:  
    storage: 1Gi  
  accessModes:  
    - ReadOnlyMany  
  nfs:  
    path: /data/volume/v1  
    server: 172.16.1.30

在 Kubernetes 中,Persistent Volume(PV)通过访问模式(Access Modes)来定义如何被 Pod 挂载和使用。访问模式对 PV 的使用场景有着重要的影响,它决定了 Pod 如何在节点间使用存储资源。
访问模式(Access Modes)

  1. ReadWriteOnce (RWO) :

    • 描述: 卷可以被单个节点以读写模式挂载。
    • 典型使用场景: 数据库、日志管理等需要读写操作且通常只会运行在单个节点上的应用。
    • 限制: 一旦一个节点已经使用此模式挂载卷,其他节点无法再以读写方式挂载。
  2. ReadOnlyMany (ROX) :

    • 描述: 卷可以被多个节点以只读模式挂载。
    • 典型使用场景: 静态内容服务器、共享配置或数据分发等无需写入操作的场景。
    • 优势: 允许在多个节点上同时读取,适用于水平扩展的读取密集型服务。
  3. ReadWriteMany (RWX) :

    • 描述: 卷可以被多个节点以读写模式挂载。
    • 典型使用场景: 需要多个实例共同读写共享数据的应用,如并行处理框架。
    • 限制: 并非所有存储系统都支持此模式,需要了解底层存储的具体支持情况。
      在这里插入图片描述
      回收策略
      在 Kubernetes 中,持久卷(PV)的回收策略(Reclaim Policy)是在 PV 的定义中指定的。这个策略决定了当一个绑定的 PVC 被删除后,PV 的处理方式。有以下几种回收策略:
  4. Retain

    • 这种策略意味着即使 PVC 被删除,PV 仍然会保留,转变为 Released 状态。
    • 数据仍留在 PV 中,未被清除。
    • 需要管理员手动处理 PV 才能重新使用,比如清除数据或重新绑定,适用于数据需要审查或备份的场景。
  5. Delete

    • 当与之绑定的 PVC 被删除时,PV 及其后端存储资产也会被自动删除。
    • 适用于不需要保留数据的场景,比如临时数据存储。
    • 常见于动态供应的存储系统中。
  6. Recycle(已弃用):

    • 该策略会简单地擦除 PV 上的数据,并将 PV 标记为 Available,供再次使用。
    • 在 Kubernetes 版本 1.15 已被弃用,建议使用其他更现代的存储策略。

如何设置回收策略

回收策略在 PersistentVolume(PV)的配置文件中进行定义。以下是一个定义 PV 及其回收策略的示例:

apiVersion: v1  
kind: PersistentVolume  
metadata:  
  name: example-pv  
spec:  
  capacity:  
    storage: 10Gi  
  accessModes:  
    - ReadWriteOnce  
  persistentVolumeReclaimPolicy: Retain  
  nfs:  
    path: /path/to/nfs  
    server: nfs-server.example.com  

在配置文件中的设置位置

  • persistentVolumeReclaimPolicy 字段:这是在 PV 规格(spec)下定义的,它指定了 PV 的回收策略。可选的值为 RetainDelete
  • 默认策略:如果未指定,Kubernetes 将使用默认的 Retain 策略。这意味着数据会保留,除非明确设置为 Delete

通过合理配置回收策略,可以有效管理存储资源,确保在应用需要时存储行为符合期望的数据处理和安全策略。

(3)创建pvc

apiVersion: v1
kind: PersistentVolumeClaim  
metadata:  
  name: my-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi

在这里插入图片描述
这边有一个问题,并没有指定pvc去找哪个pv,而且我设置的pv的限制也不相同,他们是如何寻找并绑定的呢?
PVC 和 PV 的自动匹配和绑定

  1. 自动匹配和绑定

    • Kubernetes 控制平面的控制循环持续监控新创建的 PVC。
    • 当新的 PVC 被创建时,控制器寻找能够满足其要求的可用 PV。
    • 如果找到匹配的 PV,系统会自动绑定 PVC 和 PV。
  2. 等待和绑定

    • 如果没有适合的 PV(例如缺少足够的存储大小或不匹配的访问模式),PVC 将保持未绑定状态。
    • 当一个匹配的 PV 后续被创建或释放时,此 PVC 将自动与之绑定。
    • 例如,若 PVC 请求 100 Gi 的存储而集群中只有多个 50 Gi 的 PV,则 PVC 会等待,直到有一个 100 Gi 的 PV 可用。
  3. 在 Pod 中使用 PVC

    • Pod 使用 PVC 申领的存储卷,Kubernetes 将根据 PVC 的绑定信息找到对应的 PV 并挂载到 Pod 上。
    • 如果 PV 支持多种访问模式,用户在 Pod 中使用 PVC 时需指定希望的访问模式。
  4. 持久绑定关系

    • 一旦 PVC 与 PV 绑定成功,PV 就专属于该 PVC,直到 PVC 被删除。
    • 用户通过在 Pod 规格中的 volumes 字段中引用 persistentVolumeClaim 节区来使用已申领的 PV。

(4)创建pod

apiVersion: v1  
kind: Pod  
metadata:  
  name: pod-pvc  
spec:  
  containers:  
  - name: nginx  
    image: harbor.hiuiu.com/nginx/nginx:1.21.5  
    imagePullPolicy: IfNotPresent  
    volumeMounts:  
    - name: nginx-html  
      mountPath: /usr/share/nginx/html  
  volumes:  
  - name: nginx-html  
    persistentVolumeClaim:  
      claimName: my-pvc

在这里插入图片描述
(5)验证效果
由于选的pv是/data/disk/v2,所以我们选择在v2下编写index.html文件。然后去访问相应的pod。
在这里插入图片描述
在这里插入图片描述

StorageClass

在 Kubernetes 中,StorageClass 是用于定义和管理持久卷(Persistent Volume, PV)动态供应的配置方法。通过 StorageClass,管理员可以抽象出底层存储实现的细节,并提供一种灵活的资源分配机制。以下是 StorageClass 的详细解释及其应用场景:

StorageClass 概述

  1. 定义:

    • StorageClass 是 Kubernetes 的一种资源对象,用来定义如何为 Persistent Volume Claim (PVC) 动态创建和配置 Persistent Volume (PV)。
    • 包含的信息通常包括存储类型、参数、供应策略等。
  2. 关键属性:

    • provisioner: 指定用于动态创建存储的插件或驱动程序。
    • parameters: 包含配置 provisioner 所需的参数,如存储类型、区位信息等。
    • reclaimPolicy: 定义当 PVC 删除后 PV 的回收策略(如 RetainDelete)。
    • volumeBindingMode: 指定卷绑定时间,可以是 Immediate(即时)或 WaitForFirstConsumer(等待第一个消费者)。
  3. 动态供应:

    • 使用 StorageClass 可以实现 PV 的动态供应,当 PVC 请求存储时,系统根据相关 StorageClass 创建符合需求的 PV。
    • 动态供应常用于云环境中,通过自动化的方式减少手动干预。

应用场景

  1. 多种存储类型管理:

    • 在同一集群中管理不同的存储类型,比如高性能 SSD 和低成本 HDD,为不同的工作负载提供更合适的存储解决方案。
  2. 按需分配资源:

    • 动态供应可根据应用需求自动分配存储资源,而不是预先分配所有存储,提高资源效率和利用率。
  3. 支持不同应用需求:

    • 不同的应用程序可能需要不同的存储特性(如速度、容量、备份机制等)。利用不同的 StorageClass 可以为每种需求提供个性化解决方案。
  4. 跨区域的可用性:

    • 对于分布式应用,通过 StorageClass 可以指定存储的区域或可用区,提升数据访问的延迟性能和冗余度。
  5. 简化运维:

    • 集群管理员可以通过 StorageClass 统一管理存储策略和配置,简化了复杂的存储管理任务。

实际应用

(1)创建一个SA账户
在 Kubernetes 中,“ServiceAccount”(服务账户,缩写为 SA)是一种用于管理应用在集群内运行时访问 API 服务器的身份标识。

apiVersion: v1  
kind: ServiceAccount  
metadata:  
  name: nfs-provisioner

在这里插入图片描述
(2)对sa授权

 kubectl create clusterrolebinding nfs-provisioner-clusterrolebinding --clusterrole=cluster-admin --serviceaccount=default:nfs-provisioner

(3)创建StorageClass

apiVersion: storage.k8s.io/v1  
kind: StorageClass  
metadata:  
  name: nfs  
provisioner: example.com/nfs

定义了资源的类型为 StorageClass。
NFS provisioner,用于该 StorageClass。provisioner 是存储提供者(插件或驱动)的标识符。通常你会用实际的 provisioner 名称,如 nfs-provisioner。
(4)构建一个provisioner,用于动态创建pv

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: nfs-provisioner  
spec:  
  selector:  
    matchLabels:  
      app: nfs-provisioner  
  replicas: 1  
  strategy:  
    type: Recreate  
  template:  
    metadata:  
      labels:  
        app: nfs-provisioner  
    spec:  
      serviceAccount: nfs-provisioner  
      containers:  
        - name: nfs-provisioner  
          image: registry.cn-beijing.aliyuncs.com/mydlq/nfs-subdir-external-provisioner:v4.0.0  
          volumeMounts:  
            - name: nfs-client-root  
              mountPath: /persistentvolumes  
          env:  
            - name: PROVISIONER_NAME  
              value: example.com/nfs  
            - name: NFS_SERVER  
              value: 192.168.232.100  
            - name: NFS_PATH  
              value: /data/nfs
      volumes:  
        - name: nfs-client-root  
          nfs:  
            server: 192.168.232.100 
            path: /data/nfs

(5)准备nfs存储
(6)创建pvc

apiVersion: v1  
kind: PersistentVolumeClaim  
metadata:  
  name: test-claim1  
spec:  
  accessModes:  
    - ReadWriteMany  
  resources:  
    requests:  
      storage: 1Gi  
  storageClassName: nfs

(7)创建测试pod

apiVersion: v1  
kind: Pod  
metadata:  
  name: read-pod  
spec:  
  containers:  
    - name: read-pod  
      image: harbor.hiuiu.com/nginx/nginx:1.21.5  
      volumeMounts:  
        - name: nfs-pvc  
          mountPath: /usr/share/nginx/html  
  restartPolicy: Never  
  volumes:  
    - name: nfs-pvc  
      persistentVolumeClaim:  
        claimName: test-claim1

在这里插入图片描述
注意:需要给挂载文件夹的权限。否则文件夹挂载不上去。
(8)验证
进入容器去构建index.html
在这里插入图片描述

在这里插入图片描述
挂载路径下面也有。实验成功。

  • 27
    点赞
  • 17
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
PV(PersistentVolume)和PVC(PersistentVolumeClaim)是Kubernetes中用于实现持久化存储的重要概念。 PV是集群中的一块存储,可以是NFS、iSCSI、本地存储等,由管理员进行配置或使用存储类进行动态配置。PV定义了存储的容量、访问模式、持久化存储的类型等属性。PV的生命周期是独立于Pod的,即使Pod被删除,PV仍然存在,可以被其他Pod继续使用。 PVC是一个持久化存储卷,用于访问各种类型的持久化存储,如本地存储、网络存储、云存储等。PVC的使用使应用程序更加灵活和可移植,同时也提高了存储资源的利用率。PVC和PV是一一对应的关系,即一个PVC只能绑定一个PV,而一个PV也只能被一个PVC绑定。 下面是一个演示k8s持久化存储PV和PVC的案例: 1. 创建PV: ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: my-pv spec: capacity: storage: 1Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: my-storage-class nfs: path: /data server: nfs-server-ip ``` 2. 创建PVC: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: my-storage-class ``` 3. 创建Pod,并挂载PVC卷: ```yaml apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: nginx volumeMounts: - name: my-volume mountPath: /data volumes: - name: my-volume persistentVolumeClaim: claimName: my-pvc ``` 4. 删除PVC的正确步骤: ```shell kubectl delete pod my-pod kubectl delete pvc my-pvc kubectl delete pv my-pv ```
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值