10. Kubernetes进阶篇-持久存储

王茗渠

于 2024-07-23 21:31:30 发布

阅读量491

点赞数 21

分类专栏： Kubernetes 文章标签： kubernetes

本文链接：https://blog.csdn.net/weixin_40901913/article/details/140646742

版权

Kubernetes 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

VOLUME

概念

什么是VOLUME

Volume 是一个抽象层，用于在 Pod 中提供长期存储。
Pod 中的容器可以使用 Volume 来持久化数据，例如数据库、日志文件、配置文件等。
Volume 可以挂载到容器内部，使其能够读取和写入 Volume 的数据。

主要特点和用途

持久化数据：Volume 允许 Pod 中的容器持久化数据，即使在 Pod 被删除后，Volume 中的数据也不会丢失。
多容器共享：一个 Volume 可以被多个容器共享，允许 Pod 中的多个容器访问同一组数据。
支持多种存储后端：Volume 支持多种存储后端，包括本地存储、网络存储和托管存储。
声明式配置：Volume 是声明式的，这意味着你可以指定 Volume 的类型和配置，而 Kubernetes 会负责创建和管理 Volume。
支持自动挂载：Volume 支持自动挂载，容器可以自动访问 Volume，而不需要手动挂载。
支持自动创建和删除：当 Pod 被创建时，Volume 会自动创建；当 Pod 被删除时，Volume 也会自动删除。
支持存储类：Volume 支持存储类（StorageClass），允许你指定存储后端的类型和配置。
支持多种存储类型：Volume 支持多种存储类型，包括本地存储、网络存储和托管存储。
支持存储优化：Volume 支持存储优化，例如快照、备份和复制等。
支持访问控制：Volume 支持访问控制，例如权限控制和 ACL 等。

EmptyDir

什么是emptyDir

EmptyDir 卷是一种特殊的卷类型，它提供了一种方式，可以在 Pod 之间共享存储，同时允许这些 Pod 中的容器在卷中写入和读取数据。
EmptyDir 卷是在 Pod 被创建时动态创建的，它不会占用集群中的任何存储资源，直到 Pod 被调度并运行。
EmptyDir 卷主要用于数据共享，在Pod被删除后是会被清空的。
EmptyDir 卷可以使用内存来共享数据，但内存的大小会被计算到容器中，并且受容器内存限制。

主要特点和用途

动态创建：EmptyDir 卷在 Pod 被创建时自动创建，在 Pod 被删除时自动删除。
数据持久化：EmptyDir 卷中的数据在 Pod 的生命周期内是持久的，即使 Pod 被重新调度到不同的节点。
多容器共享：一个 EmptyDir 卷可以被同一个 Pod 中的多个容器共享。
数据卷生命周期：EmptyDir 卷的生命周期与 Pod 相同，它会在 Pod 被删除时被删除。
数据不共享：EmptyDir 卷中的数据不会在不同的 Pod 之间共享，每个 Pod 都有自己独立的 EmptyDir 卷。
不持久化：EmptyDir 卷的数据不会被持久化到集群之外的存储中，它只存在于 Pod 所在的节点上。
顺序一致性：EmptyDir 卷中的数据访问是顺序一致的，即如果多个容器尝试同时写入 EmptyDir 卷，它们将按顺序写入，不会发生冲突。
使用场景：EmptyDir 卷适用于需要多个容器之间共享临时数据的情况，例如日志聚合、缓存数据等。

**注意：**一般不使用内存共享数据，因为数据量越大，内存消耗越大会影响业务。

如何应用EmptyDir

编辑yaml实现数据共享

apiVersion: apps/v1
kind: Deployment                                                                    #表示这是一个 Deployment 资源。
metadata:
  name: deployment-busybox                                                          #定义了 Deployment 的名称。
  namespace: default
  labels:
    app: deployment-busybox

spec:
  selector:                                                                         #使用标签选择器 matchLabels: app: busybox 来选择与 Deployment 模板中的 Pod 标签匹配的 Pod。
    matchLabels:
      app: busybox
  template:                                                                         #定义了 Pod 的模板，包括容器、标签和端口等信息。
    metadata:
      labels:
        app: busybox
    spec:
      containers:                                                                   #定义了容器的模板
        - name: busybox-01                                                          #定义了容器的名称，busybox-01
          image: registry.cn-beijing.aliyuncs.com/publicspaces/busybox:1.28.0
          imagePullPolicy: IfNotPresent
          command:
            - sleep
            - "3600"
          volumeMounts:
            - mountPath: /tmp/test                                                  #定义了卷的挂载路径。
              name: busybox-volume                                                  #定义了卷的名称，这个卷将在 volumes 部分定义。两个容器使用相同的VOLUME可以实现文件共享

        - name: busybox-02                                                          #定义了容器的名称，busybox-02
          image: registry.cn-beijing.aliyuncs.com/publicspaces/busybox:1.28.0
          imagePullPolicy: IfNotPresent
          command:
            - sleep
            - "3600"
          volumeMounts:
            - mountPath: /opt/test                                                  #定义了卷的挂载路径。
              name: busybox-volume                                                  #定义了卷的名称，这个卷将在 volumes 部分定义。两个容器使用相同的VOLUME可以实现文件共享
      restartPolicy: Always
      volumes:                                                                      #定义了 Pod 使用的卷。
        - name: busybox-volume                                                      #定义了卷的名称。
          emptyDir:                                                                 #定义了该卷是一个 EmptyDir 类型的卷。这意味着卷将在 Pod 被创建时自动创建，并在 Pod 被删除时自动删除。
            {}

创建服务

kubectl create -f volume-emptydir-busybox.yaml

验证Pod间数据共享

#容器busybox-01挂载Volume的目录中创建数据
kubectl exec -it deployment-busybox-55fdc884cd-q5zzz -c busybox-01 -- sh
# / # echo "test share dir" > /tmp/test/file.txt

#容器busybox-02挂载Volume的目录中读取数据
kubectl exec -it deployment-busybox-55fdc884cd-q5zzz -c busybox-02 -- sh
# / # cat /opt/test/file.txt 
# test share dir

HostPath

什么是HostPath

HostPath 卷是一种特殊的卷类型，它允许你直接挂载宿主机的文件系统或目录到 Pod 中。
HostPath 卷可以用于访问宿主机上的文件系统，这对于测试、调试或需要访问宿主机文件系统的情况非常有用。

主要特点和用途

访问宿主机文件系统：HostPath 卷允许 Pod 直接访问宿主机的文件系统或目录。
数据持久化：HostPath 卷中的数据在 Pod 的生命周期内是持久的，即使 Pod 被重新调度到不同的节点。
数据卷生命周期：HostPath 卷的生命周期与 Pod 相同，它会在 Pod 被删除时被删除。
不支持多容器共享：HostPath 卷不能被同一个 Pod 中的多个容器共享。
不支持持久化存储：HostPath 卷不会将数据持久化到集群之外的存储中，它只存在于 Pod 所在的节点上。
使用场景：HostPath 卷适用于需要访问宿主机文件系统的情况，例如运行容器化的应用程序时需要访问宿主机的文件系统。

**注意：**一般不适用此挂载方式，除非固定此Pod运行的Node，否则将无法正常挂载宿主机的目录。

常用类型扩展

DirectoryOrCreate：

如果宿主机上的路径是一个目录，则直接挂载该目录。
如果宿主机上的路径不是一个目录，则在创建时自动创建一个目录。

Directory：

宿主机上的路径必须是一个已存在的目录。
如果路径不存在，则 Kubernetes 不会自动创建它。

FileOrCreate：

如果宿主机上的路径是一个文件，则直接挂载该文件。
如果宿主机上的路径不是一个文件，则在创建时自动创建一个文件。

File：

如果宿主机上的路径是一个文件，则直接挂载该文件。
如果宿主机上的路径不是一个文件，则 Kubernetes 不会自动创建它。

Socket：

如果宿主机上的路径是一个UNIX套接字，则直接挂载该UNIX套接字。
如果宿主机上的路径不是一个UNIX套接字，则 Kubernetes 不会自动创建它。

CharDevice：

如果宿主机上的路径是一个字符设备，则直接挂载该字符设备。
如果宿主机上的路径不是一个字符设备，则 Kubernetes 不会自动创建它。

BlockDevice：

如果宿主机上的路径是一个块设备，则直接挂载该块设备。
如果宿主机上的路径不是一个块设备，则 Kubernetes 不会自动创建它。

如何使用HostPath

mkdir -p /data/deployment/busybox/data/

apiVersion: apps/v1
kind: Deployment                                                                      #表示这是一个 Deployment 资源。
metadata:
  name: deployment-busybox                                                            #定义了 Deployment 的名称。
  namespace: default
  labels:
    app: deployment-busybox                                                           #定义了 Deployment 的标签

spec:
  selector:                                                                           #使用标签选择器 matchLabels: app: busybox 来选择与 Deployment 模板中的 Pod 标签匹配的 Pod。
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      nodeName: k8s-01                                                                #这意味着 Deployment 中的 Pod 将会被调度到名为 k8s-01 的节点上。
      containers:
        - name: busybox                                                               #定义了容器的名称。
          imagePullPolicy: IfNotPresent
          image: registry.cn-beijing.aliyuncs.com/publicspaces/busybox:1.28.0
          command:
            - sleep
            - "3600"
          volumeMounts:                                                               #定义了容器挂载的卷。
            - mountPath: /tmp/test                                                    #定义了卷的挂载路径。
              name: hostpath-volume                                                   #定义了卷的名称，这个卷将在 volumes 部分定义。
      volumes:
        - name: hostpath-volume                                                       #定义了卷的名称。
          hostPath:                                                                   #定义了该卷是一个 HostPath 类型的卷。
            path: /data/deployment/busybox/data/                                      #定义了宿主机的路径，这个路径将直接挂载到 Pod 中。
            type: Directory																														#指定HostPath挂载的是一个已经存在的目录，当type为空时不会进程任何检查

创建服务

kubectl create -f volume-hostpath-busybox.yaml

#宿主机volume定义的下创建文件
echo "test hostpath file" > /data/deployment/busybox/data/test.file

#容器中查看创建的文件
kubectl exec -it deployment-busybox-6b5b6c78cc-k5p6n -- sh
# / # cat /tmp/test/test.file 
# test hostpath file

NFS

什么是NFS

NFS（网络文件系统，Network File System）是一个网络文件系统协议，它允许不同的计算机系统通过网络共享文件和目录。
在 Kubernetes 中，NFS 通常被用作持久化存储的解决方案，允许 Pod 访问远程服务器上的文件系统。

主要特点和用途

持久化存储：NFS 允许 Pod 访问远程服务器上的文件系统，从而为 Pod 提供持久化存储。
共享文件系统：NFS 允许不同节点上的 Pod 共享同一文件系统，这对于需要多个节点间共享数据的应用程序非常有用。
数据持久化：NFS 提供了数据持久化的能力，即使 Pod 被删除或重新调度，存储在 NFS 上的数据也不会丢失。
数据共享：NFS 允许 Pod 共享同一文件系统中的数据，这对于需要多个容器访问同一数据集的应用程序非常有用。
使用场景：NFS 适用于需要持久化存储和多节点间数据共享的场景，例如大数据处理、分布式存储等。

如何使用NFS

NFS服务
- 默认已经完成NFS服务的创建
- NFS服务的IP：192.168.23.139
- NFS服务的Dir：/data/nfs/data/
编辑yaml实现NFS挂载

apiVersion: apps/v1
kind: Deployment                                                                    #表示这是一个 Deployment 资源。
metadata:
  name: deployment-busybox                                                          #定义了 Deployment 的名称。
  namespace: default
  labels:
    app: deployment-busybox

spec:
  selector:                                                                         #使用标签选择器 matchLabels: app: busybox 来选择与 Deployment 模板中的 Pod 标签匹配的 Pod。
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
        - name: busybox
          image: registry.cn-beijing.aliyuncs.com/publicspaces/busybox:1.28.0
          imagePullPolicy: IfNotPresent
          command:
            - sleep
            - "3600"
          volumeMounts:                                                             #定义了容器挂载的卷。
            - mountPath: /tmp/test/                                                 #定义了卷的挂载路径。
              name: nfs-volume                                                      #定义了卷的名称，这个卷将在 volumes 部分定义。
      volumes:                                                                      #定义了 Pod 使用的卷。
        - name: nfs-volume                                                          #定义了卷的名称。
          nfs:                                                                      #定义了该卷是一个 NFS 类型的卷。
            path: /data/nfs/data/                                                   #定义了 NFS 共享的路径。
            server: 192.168.23.138                                                  #定义了 NFS 服务器的 IP 地址。

创建服务

kubectl create -f volume-nfs-busybox.yaml

验证Pod挂载NFS

#/data/nfs/data/目录下创建文件
echo "test nfs file" > /data/nfs/data/file.txt

#容器中查看数据
kubectl exec -it deployment-busybox-6b5b6c78cc-k5p6n -- sh
# / # cat /tmp/test/file.txt
# test nfs file

PV&PVC

简介

什么是PV

PersistentVolume（PV）是一个抽象层，它提供了一种方式，可以在集群中为 Pod 提供持久化存储。
PersistentVolume 允许你指定存储类型和配置，而 Kubernetes 负责创建和管理存储资源。

PV的主要特点和用途

持久化存储：PersistentVolume 允许 Pod 访问持久化存储，即使在 Pod 被删除后，存储的数据也不会丢失。
声明式配置：PersistentVolume 是声明式的，这意味着你可以指定存储的类型和配置，而 Kubernetes 会负责创建和管理存储资源。
支持多种存储后端：PersistentVolume 支持多种存储后端，包括 NFS、GlusterFS、Ceph 等。
支持自动创建和删除：当 Pod 被创建时，PersistentVolume 会自动创建；当 Pod 被删除时，PersistentVolume 也会自动删除。
支持访问控制：PersistentVolume 支持访问控制，例如权限控制和 ACL 等。
支持存储优化：PersistentVolume 支持存储优化，例如快照、备份和复制等。

什么是PVC

PersistentVolumeClaim（PVC）是一个抽象层，它提供了一种方式，可以在 Pod 中请求和使用 PersistentVolume（PV）提供的持久化存储。
PersistentVolumeClaim 允许你指定存储类型和配置，而 Kubernetes 负责管理存储资源。

PVC的主要特点和用途

请求存储资源：PersistentVolumeClaim 允许 Pod 请求和使用 PersistentVolume 提供的存储资源。
声明式配置：PersistentVolumeClaim 是声明式的，这意味着你可以指定存储的类型和配置，而 Kubernetes 会负责管理存储资源。
支持多种存储后端：PersistentVolumeClaim 支持多种存储后端，包括 NFS、GlusterFS、Ceph 等。
支持自动创建和删除：当 Pod 被创建时，PersistentVolumeClaim 会自动创建；当 Pod 被删除时，PersistentVolumeClaim 也会自动删除。
支持访问控制：PersistentVolumeClaim 支持访问控制，例如权限控制和 ACL 等。
支持存储优化：PersistentVolumeClaim 支持存储优化，例如快照、备份和复制等。

PV&PVC工作原理

工作原理解释

首先PV会先绑定已经创建好的存储资源，如Ceph、NFS等；
如果运行一个Deployment，Deployment创建的Pod想要使用这些存储资源，那么容器要挂载PVC；
再由VC到PV那里申请存储资源；
一个pod可以绑定多个PVC，同时一个PVC也可以用于多个Pod；

工作原理图示

注意事项

一般一个PV连接一类存储，如一个PV连接NFS、一个PV连接Ceph。
PV没有namespace概念而PVC有；使用命令查看：kubectl api-resources --namespace=true | grep pv。
创建PVC后，一直绑定不上PV，PVC出现Pending：
PVC申请的存储空间大于了PV的存储空间大小。
PVC的storageClassName没有和PV的保持一致。
PVC的accessModes没有和PV的保持一致。
创建挂载PVC的POD后，POD出现Pending：
PVC没有被创建成功。
PVC和POD不在同一个Namespace下。

概念

PV的策略（persistentVolumeReclaimPolicy）

定义了 PV 的生命周期和回收策略。

Recycle：
- 自动回收策略，当 PV 被释放时，PV 将被自动清理，以便可以被重新使用。
- 默认策略，如果未指定其他策略，PV 将被自动回收。
Retain：
- 手动回收策略，当 PV 被释放时，PV 不会被自动清理，需要手动进行清理。
- 如果需要保留 PV 中的数据，即使 Pod 被删除，也可以选择保留 PV。
Recycle：
- 自动回收策略，当 PV 被释放时，PV 将被自动清理，以便可以被重新使用。
- 默认策略，如果未指定其他策略，PV 将被自动回收。

PersistentVolume 的策略可以通过 persistentVolumeReclaimPolicy 字段来指定。

PV的类型

根据 PV 的创建方式和存储后端类型可以分为动态 PV 和静态 PV，以及本地 PV 和远程 PV。

动态 PV (Dynamic Provisioning)：

动态 PV 是通过 Kubernetes 的 StorageClass API 动态创建的。
当你创建一个 PersistentVolumeClaim (PVC) 时，Kubernetes 会自动创建一个 PV 来满足这个 PVC 的需求。
动态 PV 通常与 StorageClass 一起使用，StorageClass 定义了存储提供者和存储类型。
适用于生产环境，可以自动创建和管理 PV。

静态 PV (Static Provisioning)：

静态 PV 是手动创建的，不是通过 StorageClass API 动态创建的。
你需要手动定义 PV 的 YAML 文件，然后使用 kubectl apply 命令来创建 PV。
静态 PV 通常用于特定的测试或开发环境，因为它们需要手动管理。

本地 PV (Local PV)：

本地 PV 使用宿主机的文件系统作为存储。
它们通常用于简单的测试或开发环境，因为它们提供了有限的存储容量和性能。
本地 PV 可以通过 type: Directory 或 type: File 来指定宿主机路径的类型。

远程 PV (Remote PV)：

远程 PV 使用外部存储系统作为存储后端，如 NFS、Ceph、GlusterFS 等。
它们通常用于生产环境，因为它们提供了更大的存储容量和更好的性能。
远程 PV 可以通过 nfs, glusterfs, cephfs, iscsi, rbd, flexVolume, flocker, hostPath, azureFile, azureDisk, gcePersistentDisk, awsElasticBlockStore, portworxVolume, scaleIO, storageos 等类型来指定存储后端。

PV的访问（accessModes）

PersistentVolume（PV）和 PersistentVolumeClaim（PVC）的 accessModes 字段定义了如何访问存储。
accessModes 字段是一个数组，可以包含多个值，每个值表示一种访问模式。

ReadWriteOnce：
- 缩写RWO
- 只允许一个客户端（Pod）读写 PV。
- 适用于需要独占访问的 PV，例如数据库或日志存储。
ReadWriteMany：
- 缩写RWX
- 允许多个客户端（Pod）同时读写 PV。
- 适用于需要共享访问的 PV，例如多用户文件存储。
ReadOnlyMany：
- 缩写ROX
- 允许多个客户端（Pod）同时只读 PV。
- 适用于需要共享访问的 PV，但只读的场景，例如只读文件存储。

NFS支持以上三种类型，ISCI仅不支持ReadWriteMany类型，HostPath不支持ReadOnlyMany和ReadWriteMany。

PV的存储（volumeMode）

PV与PVC定义的模式必须一致。

文件系统（Filesystem）

定义：文件系统类型的PV提供了一个预先格式化的文件系统，Pod可以通过PersistentVolumeClaim (PVC) 将其挂载到自己的文件系统中。
使用：当Pod需要访问文件系统中的文件时，可以使用文件系统类型的PV。这适用于大多数需要读写文件的应用程序。
示例：NFS、HostPath、GlusterFS等。

**块存储（Block） **

定义：块存储类型的PV提供了一个原始的块设备，可以直接挂载到Pod中，或者被格式化并挂载为文件系统。
使用：当应用程序需要直接访问块设备，或者需要高性能的存储访问时，可以使用块存储。例如，数据库系统通常需要块存储来优化性能。
示例：iSCSI、FC (Fibre Channel)、AWS EBS、GCE Persistent Disk、Azure Disk等。

RBD（RADOS Block Device）

定义：RBD是Ceph分布式存储系统中的一个块设备，它提供了一个高性能、可扩展和可靠的对象存储解决方案。
使用：当需要高可用性和可扩展性的存储解决方案时，RBD是一个很好的选择。它特别适合于大规模的数据存储需求。
示例：Ceph RBD。

PersistentVolume (PV) 可以使用不同的存储类型来满足不同的需求。

PV的状态

PersistentVolume (PV) 有四种可能的的状态，这些状态反映了PV的生命周期和使用情况。

Available（可用）

描述：这个状态的PV尚未被任何PersistentVolumeClaim (PVC) 绑定，因此它是可用的，可以被新的PVC所使用。
条件：PV没有被绑定到任何PVC，且没有任何Pod正在使用它。

Bound（已绑定）

描述：当PV被PVC成功绑定后，它就进入了“Bound”状态。这意味着PV已经被分配给了特定的PVC，并且只能由该PVC使用。
条件：PV已经和一个PVC绑定，并且PVC处于活动状态。

Released（已释放）

描述：当PVC被删除后，与之绑定的PV将进入“Released”状态。在这个状态下，PV仍然保留了之前的数据，但不再被任何PVC所使用。
条件：PV之前被PVC绑定，但PVC已经被删除。

Failed（失败）

描述：如果PV无法成功被绑定到PVC或者无法正常工作，它将进入“Failed”状态。这通常是由于外部存储系统的问题或者配置错误导致的。
条件：PV无法绑定到PVC，或者存储资源出现故障。

状态转换通常如下

Available -> Bound：当一个新的PVC被创建并且与一个未绑定的PV匹配时，PV将从“Available”状态转换为“Bound”状态。
Bound -> Released：当与PV绑定的PVC被删除时，PV将转换为“Released”状态。
Released -> Available：管理员可以选择手动回收PV，清理数据后将其重新标记为“Available”状态供后续使用。
任何状态 -> Failed：如果PV遇到问题，它可能会进入“Failed”状态。

PVC的访问

ReadWriteOnce：
- 只允许一个客户端（Pod）读写 PV。
- 适用于需要独占访问的 PV，例如数据库或日志存储。
ReadWriteMany：
- 允许多个客户端（Pod）同时读写 PV。
- 适用于需要共享访问的 PV，例如多用户文件存储。
ReadOnlyMany：
- 允许多个客户端（Pod）同时只读 PV。
- 适用于需要共享访问的 PV，但只读的场景，例如只读文件存储。

NFS支持以上三种类型，ISCI仅不支持ReadWriteMany类型，HostPath不支持ReadOnlyMany和ReadWriteMany。

PVC的存储

PV与PVC定义的模式必须一致。

文件系统（Filesystem）

定义：文件系统类型的PV提供了一个预先格式化的文件系统，Pod可以通过PersistentVolumeClaim (PVC) 将其挂载到自己的文件系统中。
使用：当Pod需要访问文件系统中的文件时，可以使用文件系统类型的PV。这适用于大多数需要读写文件的应用程序。
示例：NFS、HostPath、GlusterFS等。

**块存储（Block） **

定义：块存储类型的PV提供了一个原始的块设备，可以直接挂载到Pod中，或者被格式化并挂载为文件系统。
使用：当应用程序需要直接访问块设备，或者需要高性能的存储访问时，可以使用块存储。例如，数据库系统通常需要块存储来优化性能。
示例：iSCSI、FC (Fibre Channel)、AWS EBS、GCE Persistent Disk、Azure Disk等。

RBD（RADOS Block Device）

定义：RBD是Ceph分布式存储系统中的一个块设备，它提供了一个高性能、可扩展和可靠的对象存储解决方案。
使用：当需要高可用性和可扩展性的存储解决方案时，RBD是一个很好的选择。它特别适合于大规模的数据存储需求。
示例：Ceph RBD。

创建

创建本地PV

注意

默认已经在本地创建好了目录。
使用本地PV时需要使用节点亲和力来确定PV挂载目录所在节点。

编辑yaml

apiVersion: v1
kind: PersistentVolume                        #定义资源的类型为PersistentVolume。
metadata:
  name: pv-dir                                #PV的名称。
  labels:
    app: pv-dir                               #这是一个自定义的标签，可用于筛选或关联资源

spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem                      #指定PV的卷模式为文件系统，这是默认值，也可以设置为Block以提供原始块设备。
  accessModes:                                #定义PV的访问模式。
    - ReadWriteOnce                           #卷可以被单个节点以读写模式挂载。
  persistentVolumeReclaimPolicy: Retain       #定义当PVC被删除后，PV的处理策略。Retain表示保留数据，手动回收。
  storageClassName: local
  hostPath:                                   #指定节点的本地路径。
    path: /data/dir/data/                     #节点上的本地文件系统路径。

创建PV

  kubectl create -f pv-local.yaml

查看PV

kubectl get pv
NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-local    5Gi        RWO            Retain           Available           local                   4s

创建远程PV

默认已经部署好了NFS
编辑yaml

apiVersion: v1
kind: PersistentVolume                                  #定义资源的类型为PersistentVolume。
metadata:
  name: pv-nfs                                          #PV的名称。
  labels:
    app: pv-nfs                                         #PV的标签。

spec:                                                   #定义了PV的规格说明
  capacity:                                             #定义了PV的存储能力
    storage: 5Gi                                        #定义了PV可以提供的存储容量为5GiB
  volumeMode: Filesystem                                #指定PV的卷模式为文件系统，这是默认值，也可以设置为Block以提供原始块设备。
  accessModes:                                          #定义了PV的访问模式
    - ReadWriteOnce                                     #定义了PV卷可以被单个节点以读写模式挂载
  persistentVolumeReclaimPolicy: Retain                 #定义当PVC被删除后，PV的处理策略。Retain表示保留数据，手动回收。
  storageClassName: remote                                #指定PV所属的StorageClass的名称，这里为slow
  nfs:                                                  #指定NFS服务器相关的配置。
    path: /data/nfs/data/                               #NFS服务器上共享的路径。
    server: 192.168.23.139                              #NFS服务器的IP地址。

创建PV

kubectl create -f pv-remote.yaml

查看PV

kubectl get pv
NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv-remote   5Gi        RWO            Retain           Available           remote                  5s

创建PVC

编辑yaml

apiVersion: v1
kind: PersistentVolumeClaim             #定义资源的类型为PersistentVolumeClaim。
metadata:
  name: pvc-nfs                         #PVC的名称
  namespace: default                    #指定PVC所在的命名空间，这里是默认命名空间。PVC有命名空间概念
  labels:
    app: pvc-nfs

spec:
  accessModes:                          #定义PVC的访问模式。
    - ReadWriteOnce                     #卷可以被单个节点以读写模式挂载。要与使用的PV保持一致。
  volumeMode: Filesystem                #指定PVC的卷模式为文件系统，这是默认值，也可以设置为Block以提供原始块设备。要与使用的PV保持一致。
  storageClassName: remote              #指定PVC应该使用名为remote的StorageClass来提供存储资源。要与使用的PV保持一致。
  resources:                            #定义PVC的资源请求。
    requests:                           #定义PVC所需的最小资源量。
      storage: 5Gi                      #PVC请求5GiB的存储容量。

创建PVC

kubectl create -f pvc-remote.yaml

查看PVC

kubectl get pvc
# NAME      STATUS   VOLUME      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# pvc-nfs   Bound    pv-remote   5Gi        RWO            remote         3s

查看PV

kubectl get pv
# NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS   REASON   AGE
# pv-remote   5Gi        RWO            Retain           Bound    default/pvc-nfs   remote                  14m

应用

创建Deployment使用NFS-PV

注意
- PV挂载NFS时，指定的目录需要精细划分，否则所有数据将会混到一块；
- 整体流程：先创建PV挂载存储，然后使用PVC绑定PV，最后挂载到Pod；
编辑yaml

#首先创建一个PV，指定PV挂载的存储
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-remote-nfs
  labels:
    app: pv-remote-nfs

spec:
  storageClassName: remote-nfs
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  capacity:
    storage: 10Gi
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /data/nfs/data/
    server: 192.168.23.138

---
#然后创建一个PVC，指定PVC与对应PV绑定
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-remote-nfs
  namespace: default
  labels:
    app: pvc-remote-nfs

spec:
  storageClassName: remote-nfs
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi

---
#最后创建一个Deployment，让PVC挂载到对应的Pod下
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-busybox
  namespace: default
  labels:
    app: deployment-busybox

spec:
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
        - name: busybox-01
          imagePullPolicy: IfNotPresent
          image: registry.cn-beijing.aliyuncs.com/publicspaces/busybox:1.28.0
          command:
            - sleep
            - "3600"
          volumeMounts:
            - mountPath: /tmp/test
              name: volume-pvc
        - name: busybox-02
          imagePullPolicy: IfNotPresent
          image: registry.cn-beijing.aliyuncs.com/publicspaces/busybox:1.28.0
          command:
            - sleep
            - "3600"
          volumeMounts:
            - mountPath: /opt/test
              name: volume-pvc
      volumes:
        - name: volume-pvc
          persistentVolumeClaim:
            claimName: pvc-remote-nfs

创建服务

kubectl create -f pv-pvc-deployment-pod-busybox-nfs.yaml

查看服务

#检查pod
kubectl get pod
# NAME                                  READY   STATUS    RESTARTS   AGE
# deployment-busybox-7c945b4c78-c2lbl   2/2     Running   0          8m11s

#检查deployment
kubectl get deployments.apps 
# NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
# deployment-busybox   1/1     1            1           8m34s

#检查pvc
kubectl get pvc
# NAME             STATUS   VOLUME          CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# pvc-remote-nfs   Bound    pv-remote-nfs   10Gi       RWX            remote-nfs     8m52s

#检查pv
kubectl get pv
# NAME            CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                    STORAGECLASS   REASON   AGE
# pv-remote-nfs   10Gi       RWX            Retain           Bound    default/pvc-remote-nfs   remote-nfs              9m20s

验证服务

#busybox-01容器创建数据
kubectl exec -it deployment-busybox-7c945b4c78-c2lbl -c busybox-01 -- sh
# / # touch /tmp/test/pv-pvc-nfs.txt

#busybox-02容器更改数据
kubectl exec -it deployment-busybox-7c945b4c78-c2lbl -c busybox-02 -- sh
# / # echo "test pv-pvc-sh" > /opt/test/pv-pvc-nfs.txt

#NFS查看数据
ls /data/nfs/data/
# pv-pvc-nfs.txt
cat /data/nfs/data/pv-pvc-nfs.txt 
# test pv-pvc-sh

创建Deployment使用LocalFile-PV

注意
- 使用nodeName指定已经创建好目录的node节点运行Pod。
编辑yaml

#首先创建一个PV，指定PV挂载的存储
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-local-file
  labels:
    app: pv-local-file

spec:
  storageClassName: local-file
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  capacity:
    storage: 10Gi
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/dir/data/

---
#然后创建一个PVC，指定PVC与对应PV绑定
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-local-file
  namespace: default
  labels:
    app: pvc-local-file

spec:
  storageClassName: local-file
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi

---
#最后创建一个Deployment，让PVC挂载到对应的Pod下
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-busybox
  namespace: default
  labels:
    app: deployment-busybox

spec:
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      nodeName: k8s-01
      containers:
        - name: busybox-01
          imagePullPolicy: IfNotPresent
          image: registry.cn-beijing.aliyuncs.com/publicspaces/busybox:1.28.0
          command:
            - sleep
            - "3600"
          volumeMounts:
            - mountPath: /tmp/test
              name: volume-pvc
        - name: busybox-02
          imagePullPolicy: IfNotPresent
          image: registry.cn-beijing.aliyuncs.com/publicspaces/busybox:1.28.0
          command:
            - sleep
            - "3600"
          volumeMounts:
            - mountPath: /opt/test
              name: volume-pvc
      volumes:
        - name: volume-pvc
          persistentVolumeClaim:
            claimName: pvc-local-file

创建服务

kubectl create -f pv-pvc-deployment-pod-busybox-localfile.yaml

查看服务

#检查pod
kubectl get pod
# NAME                                  READY   STATUS    RESTARTS   AGE
# deployment-busybox-848954fbbd-lwjpw   2/2     Running   0          101s

#检查deployment
kubectl get deployments.apps 
# NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
# deployment-busybox   1/1     1            1           119s

#检查pvc
kubectl get pvc
# NAME             STATUS   VOLUME          CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# pvc-local-file   Bound    pv-local-file   10Gi       RWX            local-file     2m13s

#检查pv
kubectl get pv
# NAME            CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                    STORAGECLASS   REASON   AGE
# pv-local-file   10Gi       RWX            Retain           Bound    default/pvc-local-file   local-file              2m31s

验证服务

#busybox-01容器创建数据
kubectl exec -it deployment-busybox-848954fbbd-lwjpw -c busybox-01 -- sh
# / # touch /tmp/test/pv-pvc-nfs.txt

#busybox-02容器更改数据
kubectl exec -it deployment-busybox-848954fbbd-lwjpw -c busybox-02 -- sh
# / # echo "test pv-pvc-sh" > /opt/test/pv-pvc-nfs.txt

#NFS查看数据
ls /data/dir/data/
# pv-pvc-nfs.txt
cat /data/dir/data/pv-pvc-nfs.txt 
# test pv-pvc-sh

王茗渠

关注

21
点赞
踩
6

收藏

觉得还不错? 一键收藏
0
评论
10. Kubernetes进阶篇-持久存储

EmptyDir卷是一种特殊的卷类型，它提供了一种方式，可以在 Pod 之间共享存储，同时允许这些 Pod 中的容器在卷中写入和读取数据。EmptyDir卷是在 Pod 被创建时动态创建的，它不会占用集群中的任何存储资源，直到 Pod 被调度并运行。EmptyDir卷主要用于数据共享，在Pod被删除后是会被清空的。EmptyDir卷可以使用内存来共享数据，但内存的大小会被计算到容器中，并且受容器内存限制。HostPath卷是一种特殊的卷类型，它允许你直接挂载宿主机的文件系统或目录到 Pod 中。
复制链接

扫一扫

专栏目录