首页 > 网站技巧 > 服务器 > 云和虚拟化 > 云其它 > kubernetes volume数据存储

kubernetes volume数据存储的使用解读

2025-12-22 09:08:37 作者：sxpnp

文章介绍了Kubernetes中容器的生命周期、持久化存储的实现方式,以及常见的存储卷类型,包括EmptyDir、HostPath、NFS、PV、PVC、ConfigMap和Secret等,通过这些存储卷和配置,可以实现Pod中容器之间的数据共享、持久化存储以及敏感信息的管理

写在前面：如有问题，以你为准

概述

容器的生命周期可能很短，会被频繁的创建和销毁

保存在容器中的数据也会被清除，所以要实现持久化存储（Volume）

通过将本地目录挂载到pod，一个目录可以挂载到多个pod中的容器

Volume是Pod中能够被多个容器访问的共享目录

通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储

Volume的生命周期不和Pod中的单个容器的生命周期有关，当容器终止或者重启的时候，Volume中的数据也不会丢失

kubernetes的Volume支持多种类型，比较常见的有下面的几个：

简单存储：EmptyDir、HostPath、NFS。
高级存储：PV、PVC。
配置存储：ConfigMap、Secret。

EmptyDir：pod中临时存储空间可以被多个容器挂载，实现共享目录，pod删除其也删除

HostPath：将node上的目录挂载到pod里面的容器里面，实现了持久化存储，但是没有实现存储高可用

Kubernetes 目前支持多达 28 种数据卷类型（其中大部分特定于具体的云环境如 GCE/AWS/Azure 等）

非持久性存储：

emptyDir
HostPath

网络连接性存储：

SAN：iSCSI、ScaleIO Volumes、FC (Fibre Channel)
NFS：nfs，cfs

分布式存储

Glusterfs
RBD (Ceph Block Device)
CephFS
Portworx Volumes
Quobyte Volumes

云端存储

GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
Cinder (OpenStack block storage)
VsphereVolume
StorageOS

自定义存储

FlexVolume

基本存储

EmptyDir

EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。

不是持久化数据存储，生命周期跟pod一样，一般是用于多容器共享目录

EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录，当Pod销毁时，EmptyDir中的数据也会被永久删除。

EmptyDir的用途如下：

临时空间，例如用于某些应用程序运行时所需的临时目录，且无须永久保留。
一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。

示例

接下来，通过一个容器之间的共享案例来使用描述一个EmptyDir。

在一个Pod中准备两个容器nginx和busybox，然后声明一个volume分别挂载到两个容器的目录中，然后nginx容器负责向volume中写日志，busybox中通过命令将日志内容读到控制台。

apiVersion: v1

kind: Pod

metadata:

  name: volume-emptydir

  namespace: study

spec:

  containers:

    - name: nginx

      image: nginx:1.17.1

      imagePullPolicy: IfNotPresent

      command: ["/bin/sh","-c","tail -f /var/log/nginx/access.log"]

      ports:

        - containerPort: 80

      volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录，该目录为/var/log/nginx

        - name: logs-volume # 卷名

          mountPath: /var/log/nginx # 要挂载到容器的目录，该目录且要容器必须存在

    - name: busybox

      image: busybox:1.30

      imagePullPolicy: IfNotPresent

      command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，持续读取指定文件

      # 读取的时候是前台，而kubectl logs命令就是读取前台日志/dev/stdout和/dev/stderr

      volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录，该目录为/logs

        - name: logs-volume

          mountPath: /logs

  volumes: # 声明volume，name为logs-volume，类型为emptyDir

    - name: logs-volume # 用于挂载时指定的volume名字

      emptyDir: {} # 指定volume类型

[root@master k8s]# kubectl apply -f emptydir.yaml

pod/volume-emptydir created

[root@master k8s]# kubectl get pod volume-emptydir -n study -o wide

NAME              READY   STATUS    RESTARTS   AGE    IP              NODE    NOMINATED NODE   READINESS GATES

volume-emptydir   2/2     Running   0          142m   10.244.104.44   node2   <none>           <none>

[root@master k8s]# kubectl describe pod -n study

# 访问nginx，查看busybox挂载的目录是否有信息，有则说明nginx的日志在logs-volume，且busybox也挂载了目录

[root@master k8s]# curl 10.244.104.44

<!DOCTYPE html>

<html>

<head>

<title>Welcome to nginx!</title>

[root@master k8s]# kubectl logs -f volume-emptydir -n study -c busybox

192.168.100.53 - - [19/Feb/2023:08:15:33 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.61.1" "-"

HostPath

HostPath就是将Node主机中的一个实际目录挂载到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依旧可以保存在Node节点主机上

但是一旦Node节点故障了，Pod如果转移到别的Node节点上，又会出现问题

还有就是将容器的日志导出等场景

  volumes:

  - name: test-volume

    hostPath:

      # directory location on host

      path: /data

      # this field is optional

      type: Directory # 目录必须存在指定路径

      # FileOrCreate 不会创建文件的父目录，如果挂载文件的父目录不存在，则pod启动失败

      # DirectoryOrCreate 如果不存在就创建，且权限为0755，与 Kubelet 具有相同的组和所有权

      # File 文件必须存在于给定路径

      # 如果不写type就跳过检测，则如果目录不存在，yaml创建时候也不会报错，类似于可选项

示例

apiVersion: v1

kind: Pod

metadata:

  name: volume-hostpath

  namespace: study

spec:

  containers:

    - name: nginx

      image: nginx:1.17.1

      imagePullPolicy: IfNotPresent

      ports:

        - containerPort: 80

      volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录，该目录为/var/log/nginx

        - name: logs-volume

          mountPath: /var/log/nginx

    - name: busybox

      image: busybox:1.30

      imagePullPolicy: IfNotPresent

      command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件

      volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录，该目录为/logs

        - name: logs-volume

          mountPath: /logs

  volumes: # 声明volume，name为logs-volume，类型为hostPath

    - name: logs-volume

      hostPath:

        path: /root/logs

        type: DirectoryOrCreate # 目录存在就使用，不存在就先创建再使用

  nodeName: master # 测试方便查看hostPath被挂载的目录

[root@master k8s]# kubectl apply -f emptydir.yaml

pod/volume-hostpath created

[root@master k8s]# kubectl get pod -n study -o wide

NAME              READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE   READINESS GATES

volume-hostpath   2/2     Running   0          58s   10.244.219.71   master   <none>           <none>

[root@master k8s]# curl 10.244.219.71

<!DOCTYPE html>

<html>

<head>

<title>Welcome to nginx!</title>

[root@master k8s]# cat /root/logs/access.log

192.168.100.53 - - [20/Feb/2023:06:23:56 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.61.1" "-"

subPath

subpath 主要是为了防止覆盖

使用 mountPath 挂载 /etc/nginx ，但是我告诉 kubernetes 我挂载那个文件，此时就可以使用 subPath 了，此时 Kubernetes 就只会覆盖 /etc/nginx/nginx.conf 文件

换言之，mountPath 告诉 Kubernetes 我需要覆盖容器中的那个目录，但是有了 subPath ，Kubernetes 就知道了，哦，原来你只需要覆盖 mountPath 下边的子文件啊（subPath ）

apiVersion: v1

kind: Pod

metadata:

  name: my-lamp-site

spec:

    containers:

    - name: mysql

      image: mysql

      env:

      - name: MYSQL_ROOT_PASSWORD

        value: "rootpasswd"

      volumeMounts:

      - mountPath: /var/lib/mysql

        name: site-data

        subPath: m

    - name: php

      image: php:7.0-apache

      volumeMounts:

      - mountPath: /var/www/html

        name: site-data

        subPath: m

    volumes:

    - name: site-data

      emptyDir: {}

NFS

hostpath可以实现持久化，但是没有实现高可用，但是一旦Node节点故障了，Pod如果转移到别的Node节点上，又会出现问题，而NFS就是为解决持久化存储高可用

常用的有：NFS CIFS 等

NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样，无论Pod在节点上怎么转移，只要Node和NFS的对接没有问题，数据就可以成功访问。

Master 搭建 NFS

首先需要准备NFS服务器，这里为了简单，直接在Master节点做NFS服务器。

在Master节点上安装NFS服务器：

yum install -y nfs-utils rpcbind

mkdir -pv /root/data/k8s-nfs

vim /etc/exports

# 将共享目录以读写权限暴露给192.168.100.0/24网段中的所有主机

/root/data/k8s-nfs 192.168.100.0/24(rw,no_root_squash)

# 读写权限，不使用root权限

systemctl start rpcbind

systemctl enable rpcbind

systemctl start nfs-server

systemctl enable nfs-server

在Node节点上都安装NFS服务器，目的是为了Node节点可以驱动NFS设备

# 在Node节点上安装NFS服务，不需要启动

yum -y install nfs-utils

showmount -e 192.168.100.53

mount -t  nfs 192.168.100.53:/root/data/k8s-nfs /mnt #关机后

mount -t  nfs 192.168.100.53:/root/data/k8s-nfs/mnt

示例

apiVersion: v1

kind: Pod

metadata:

  name: volume-nfs

  namespace: dev

spec:

  containers:

    - name: nginx

      image: nginx:1.17.1

      imagePullPolicy: IfNotPresent

      ports:

        - containerPort: 80

      volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录，该目录为/var/log/nginx

        - name: logs-volume

          mountPath: /var/log/nginx

    - name: busybox

      image: busybox:1.30

      imagePullPolicy: IfNotPresent

      command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令，动态读取指定文件

      volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录，该目录为/logs

        - name: logs-volume

          mountPath: /logs

  volumes: # 声明volume

    - name: logs-volume

      nfs:

        server: 192.168.100.53 # NFS服务器地址

        path: /root/data/k8s-nfs # 共享文件路径

[root@master k8s]# kubectl apply -f  emptydir.yaml

pod/volume-hostpath created

[root@master k8s]# kubectl get pod -n study -o wide

NAME              READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES

volume-hostpath   2/2     Running   0          64s   10.244.104.53   node2   <none>           <none>

[root@master k8s]# curl 10.244.104.53

[root@master k8s]# cat /root/data/k8s-nfs/access.log

192.168.100.53 - - [20/Feb/2023:07:15:55 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.61.1" "-"

192.168.100.53 - - [20/Feb/2023:07:49:20 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.61.1" "-"

高级存储（pv pvc）

概述架构

此时就要求用户会搭建NFS系统等，并且会在yaml配置nfs

由于kubernetes支持的存储系统有很多，要求客户全部掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用，kubernetes引入了PV和PVC两种资源对（类似于资源池化，pv和pvc是抽象的存储资源）

使用了PV和PVC之后，工作可以得到进一步的提升：

存储：存储工程师维护。
PV：kubernetes管理员维护。
PVC：kubernetes用户维护。

下面实操的架构：pod-pvc-pv-NFS

生命周期

PVC和PV是一一对应的，PV和PVC之间的相互作用遵循如下的生命周期。

1.资源供应：管理员手动创建底层存储和PV。

2.资源绑定：

用户创建PVC，kubernetes负责根据PVC声明去寻找PV，并绑定在用户定义好PVC之后，系统将根据PVC对存储资源的请求在以存在的PV中选择一个满足条件的。

一旦找到，就将该PV和用户定义的PVC进行绑定，用户的应用就可以使用这个PVC了。
如果找不到，PVC就会无限期的处于Pending状态，直到系统管理员创建一个符合其要求的PV。

PV一旦绑定到某个PVC上，就会被这个PVC独占，不能再和其他的PVC进行绑定了。

3.资源使用：

用户可以在Pod中像volume一样使用PVC，Pod使用Volume的定义，将PVC挂载到容器内的某个路径进行使用。

4.资源释放：

上一个 pod还有东西存在目录中
用户删除PVC来释放PV。
当存储资源使用完毕后，用户可以删除PVC，和该PVC绑定的PV将会标记为“已释放”，但是还不能立刻和其他的PVC进行绑定。通过之前PVC写入的数据可能还留在存储设备上，只有在清除之后该PV才能再次使用。

5.资源回收：

kubernetes根据PV设置的回收策略进行资源的回收。
对于PV，管理员可以设定回收策略，用于设置与之绑定的PVC释放资源之后如何处理遗留数据的问题。只有PV的存储空间完成回收，才能供新的PVC绑定和使用。

理论与使用 PV

类似于linux lvm 中的 vg

一般由kubernetes运维管理人员创建，然后提供给需要使用的人创建pvc

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv2

  # 没有namespace 是集群级别的资源，跨namespace使用

spec:

  nfs: # 存储类型，和底层正则的存储对应

    path:

    server:

  capacity: # 存储能力，目前只支持存储空间的设置

    storage: 2Gi

  accessModes: # 访问模式

    - ReadWriteOnce

    # ReadOnlyMany

    # ReadWriteMany

  storageClassName: # 存储类别

  persistentVolumeReclaimPolicy: # 回收策略

pv的关键配置参数说明：

1.存储类型：底层实际存储的类型，kubernetes支持多种存储类型，每种存储类型的配置有所不同。

2.存储能力（capacity）：目前只支持存储空间的设置（storage=1Gi），不过未来可能会加入IOPS、吞吐量等指标的配置。

3.访问模式（accessModes）：

用来描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：

ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载（单pvc挂载）。
ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载。
ReadWriteMany（RWX）：读写权限，可以被多个节点挂载。

需要注意的是，底层不同的存储类型可能支持的访问模式不同。

4.回收策略（ persistentVolumeReclaimPolicy）：

当PV不再被使用之后，对其的处理方式，目前支持三种策略：

Retain（保留）：保留数据，需要管理员手动清理数据。
Recycle（回收）：清除PV中的数据，效果相当于 rm -rf /volume/*。
Delete（删除）：和PV相连的后端存储完成volume的删除操作，常见于云服务器厂商的存储服务。

需要注意的是，底层不同的存储类型可能支持的回收策略不同。

5.存储类别（storageClassName）：PV可以通过storageClassName参数指定一个存储类别。

具有特定类型的PV只能和请求了该类别的PVC进行绑定。
未设定类别的PV只能和不请求任何类别的PVC进行绑定。

6.状态（status）：一个PV的生命周期，可能会处于4种不同的阶段。

Available（可用）：表示可用状态，还未被任何PVC绑定。
Bound（已绑定）：表示PV已经被PVC绑定。
Released（已释放）：表示PVC被删除，但是资源还没有被集群重新释放。
Failed（失败）：表示该PV的自动回收失败。

示例

mkdir -pv /root/data/{pv1,pv2,pv3}

chmod 777 -R /root/data

# 修改 NFS 的配置文件

vim /etc/exports

    /root/data/pv1     192.168.18.0/24(rw,no_root_squash)

    /root/data/pv2     192.168.18.0/24(rw,no_root_squash)

    /root/data/pv3     192.168.18.0/24(rw,no_root_squash)

systemctl restart nfs-server

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv1

spec:

  nfs: # 存储类型，和底层正则的存储对应

    path: /root/data/pv1

    server: 192.168.100.53

  capacity: # 存储能力，目前只支持存储空间的设置

    storage: 1Gi

  accessModes: # 访问模式

    - ReadWriteMany

  persistentVolumeReclaimPolicy: Retain # 回收策略



---

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv2

spec:

  nfs: # 存储类型，和底层正则的存储对应

    path: /root/data/pv2

    server: 192.168.100.53

  capacity: # 存储能力，目前只支持存储空间的设置

    storage: 2Gi

  accessModes: # 访问模式

    - ReadWriteMany

  persistentVolumeReclaimPolicy: Retain # 回收策略

 

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv3

spec:

  nfs: # 存储类型，和底层正则的存储对应

    path: /root/data/pv3

    server: 192.168.100.53

  capacity: # 存储能力，目前只支持存储空间的设置

    storage: 3Gi

  accessModes: # 访问模式

    - ReadWriteMany

  persistentVolumeReclaimPolicy: Retain # 回收策略

[root@master k8s]# kubectl apply -f pv.yaml

persistentvolume/pv1 created

persistentvolume/pv2 created

persistentvolume/pv3 created

[root@master k8s]# kubectl get pv

NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE

pv1    1Gi        RWX            Retain           Available                                   27s

pv2    2Gi        RWX            Retain           Available                                   27s

pv3    3Gi        RWX            Retain           Available                                   27s

 CLAIM 如果被使用这里会显示pvc的名字

理论与使用 PVC

PVC是对 PV 资源的申请，用来声明对存储空间、访问模式、存储类别需求信息

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: pvc

  namespace: dev

spec:

  accessModes: # 访客模式

    - ReadWriteMany

  selector: # 采用标签对PV选择

  storageClassName: # 存储类别

  resources: # 请求空间

    requests:

      storage: 5Gi

PVC的关键配置参数说明：

1.访客模式（accessModes）：用于描述用户应用对存储资源的访问权限。

必须和要连接的pv声明的访问模式要一样

ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载（单pvc挂载）。
ReadOnlyMany（ROX）：只读权限，可以被多个节点挂载。
ReadWriteMany（RWX）：读写权限，可以被多个节点挂载。

2.用于描述用户应用对存储资源的访问权限：

选择条件（selector）：通过Label Selector的设置，可使PVC对于系统中已存在的PV进行筛选。
存储类别（storageClassName）：PVC在定义时可以设定需要的后端存储的类别，只有设置了该class的pv才能被系统选出。
资源请求（resources）：描述对存储资源的请求。

优先级为

pvc（1Gi）= pv（1Gi）
同等容量的pv没有了则申请比自己大即可 pvc（1Gi）= pv（2Gi）
如果没有比自己大的，也没有相等的即失败

3.状态（status）

Bound（已绑定）：表示PVC已经绑定PV。

创建PVC后一直绑定不了PV的原因

①PVC的空间申请大小比PV的空间要大。
②PVC的storageClassName和PV的storageClassName不一致。
③PVC的accessModes和PV的accessModes不一致。

上面 pv 申请pv1:1g pv2:2g pv3:3g

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: pvc1

  namespace: study

spec:

  accessModes: # 访客模式

    - ReadWriteMany # 和pv一样

  resources: # 请求空间

    requests:

      storage: 1Gi #申请pv1



---

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: pvc2

  namespace: study

spec:

  accessModes: # 访客模式

    - ReadWriteMany

  resources: # 请求空间

    requests:

      storage: 1Gi # 上面pv1已经被申请了没有同等容量的pv，所以申请pv2（2G）



---

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: pvc3

  namespace: study

spec:

  accessModes: # 访客模式

    - ReadWriteMany

  resources: # 请求空间

    requests:

      storage: 5Gi # 没有与这个相等也没有比他大的，所以申请失败

[root@master k8s]# kubectl apply -f pvc.yaml

persistentvolumeclaim/pvc1 created

persistentvolumeclaim/pvc2 created

persistentvolumeclaim/pvc3 created

[root@master k8s]# kubectl get pvc -n study

NAME   STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE

pvc1   Bound     pv1      1Gi        RWX                           54s

pvc2   Bound     pv2      2Gi        RWX                           54s

pvc3   Pending                                                     54s

# Bound 被使用

# pvc3 没找到存储容量相等或大于所以一直在ping，可以另外创建新的pv

[root@master k8s]# kubectl get pv

NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM        STORAGECLASS   REASON   AGE

pv1    1Gi        RWX            Retain           Bound       study/pvc1                           23m

pv2    2Gi        RWX            Retain           Bound       study/pvc2                           23m

pv3    3Gi        RWX            Retain           Available                                        23m

创建pod连接 PVC

apiVersion: v1

kind: Pod

metadata:

  name: pod1

  namespace: study

spec:

  containers:

  - name: busybox

    image: busybox:1.30

    command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]

    volumeMounts:

    - name: volume

      mountPath: /root/

  volumes:

    - name: volume

      persistentVolumeClaim: # 这个字段是pvc的kind: PersistentVolumeClaim

        claimName: pvc1

        readOnly: false # 只读



---

apiVersion: v1

kind: Pod

metadata:

  name: pod2

  namespace: study

spec:

  containers:

    - name: busybox

      image: busybox:1.30

      command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]

      volumeMounts:

        - name: volume

          mountPath: /root/

  volumes:

    - name: volume

      persistentVolumeClaim:

        claimName: pvc2

        readOnly: false

[root@master k8s]# kubectl apply -f pod-pvc.yaml

pod/pod1 created

pod/pod2 created

[root@master k8s]# ls /root/data/pv1/out.txt

/root/data/pv1/out.txt

删除

[root@master k8s]# kubectl delete -f pod-pvc.yaml

pod "pod1" deleted

pod "pod2" deleted

[root@master k8s]# kubectl get pvc -n study

NAME   STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE

pvc1   Bound     pv1      1Gi        RWX                           123m

pvc2   Bound     pv2      2Gi        RWX                           123m

pvc3   Pending                                                     123m

[root@master k8s]# kubectl get pv

NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM        STORAGECLASS   REASON   AGE

pv1    1Gi        RWX            Retain           Bound       study/pvc1                           126m

pv2    2Gi        RWX            Retain           Bound       study/pvc2                           126m

pv3    3Gi        RWX            Retain           Available                                        126m

[root@master k8s]# kubectl delete -f pvc.yaml

persistentvolumeclaim "pvc1" deleted

persistentvolumeclaim "pvc2" deleted

persistentvolumeclaim "pvc3" deleted

[root@master k8s]# kubectl get pv -n study

NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM        STORAGECLASS   REASON   AGE

pv1    1Gi        RWX            Retain           Released    study/pvc1                           127m

pv2    2Gi        RWX            Retain           Released    study/pvc2                           127m

pv3    3Gi        RWX            Retain           Available                                        127m

# persistentVolumeReclaimPolicy：Retain 所以要手动释放，并重新声明

persistentVolumeReclaimPolicy：Retain

将pv从Released 变为 Available

使用edit命令删除pv中的pvc的绑定信息即可变为available

注意：先将资源拿出来备份，反正数据还没备份就被pvc使用了

[root@master k8s]# kubectl get pv -n study

NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM        STORAGECLASS   REASON   AGE

pv1    1Gi        RWX            Retain           Released    study/pvc1                           129m

pv2    2Gi        RWX            Retain           Released    study/pvc2                           129m

pv3    3Gi        RWX            Retain           Available                                        129m

[root@master k8s]# kubectl edit pv pv2 # pv1

# 删除下面字段

  claimRef:

    apiVersion: v1

    kind: PersistentVolumeClaim

    name: pvc2

    namespace: study

    resourceVersion: "849619"

    uid: fac30e1d-90a5-4e8b-9092-e6b83fd55d62

persistentvolume/pv2 edited

[root@master k8s]# kubectl get pv -n study

NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE

pv1    1Gi        RWX            Retain           Available                                   134m

pv2    2Gi        RWX            Retain           Available                                   134m

pv3    3Gi        RWX            Retain           Available                                   134m

问题

pv创建不会检测nfs的路径是否连上，哪怕nfs都没有这个配置也连不上也能创建，不会报错，甚至后续的pvc和pod连接pvc都不会报错

动态供应

静态供应：集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息，并且对集群用户可用（可见）。PV 卷对象存在于 Kubernetes API 中，可供用户消费（使用）。
动态供应：集群自动根据 PVC 创建出对应 PV 进行使用

① 集群管理员预先创建存储类（StorageClass）。

② 用户创建使用存储类的持久化存储声明(PVC：PersistentVolumeClaim)。

③ 存储持久化声明通知系统，它需要一个持久化存储(PV: PersistentVolume)。

④ 系统读取存储类的信息。

⑤ 系统基于存储类的信息，在后台自动创建 PVC 需要的 PV 。

⑥ 用户创建一个使用 PVC 的 Pod 。

⑦ Pod 中的应用通过 PVC 进行数据的持久化。

⑧ PVC 使用 PV 进行数据的最终持久化处理。

https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner

设置 NFS 动态供应

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

  name: nfs-client

provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # 指定一个供应商的名字

# or choose another name, 必须匹配 deployment 的 env PROVISIONER_NAME'

parameters:

  archiveOnDelete: "false" # 删除 PV 的时候，PV 中的内容是否备份

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: nfs-client-provisioner

  labels:

    app: nfs-client-provisioner

  namespace: default

spec:

  replicas: 1

  strategy:

    type: Recreate

  selector:

    matchLabels:

      app: nfs-client-provisioner

  template:

    metadata:

      labels:

        app: nfs-client-provisioner

    spec:

      serviceAccountName: nfs-client-provisioner

      containers:

        - name: nfs-client-provisioner

          image: ccr.ccs.tencentyun.com/gcr-containers/nfs-subdir-external-provisioner:v4.0.2

          volumeMounts:

            - name: nfs-client-root

              mountPath: /persistentvolumes

          env:

            - name: PROVISIONER_NAME

              value: k8s-sigs.io/nfs-subdir-external-provisioner

            - name: NFS_SERVER

              value: 192.168.65.100 # NFS 服务器的地址

            - name: NFS_PATH

              value: /nfs/data # NFS 服务器的共享目录

      volumes:

        - name: nfs-client-root

          nfs:

            server: 192.168.65.100

            path: /nfs/data

---

apiVersion: v1

kind: ServiceAccount

metadata:

  name: nfs-client-provisioner

  namespace: default

---

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: nfs-client-provisioner-runner

rules:

  - apiGroups: [""]

    resources: ["nodes"]

    verbs: ["get", "list", "watch"]

  - apiGroups: [""]

    resources: ["persistentvolumes"]

    verbs: ["get", "list", "watch", "create", "delete"]

  - apiGroups: [""]

    resources: ["persistentvolumeclaims"]

    verbs: ["get", "list", "watch", "update"]

  - apiGroups: ["storage.k8s.io"]

    resources: ["storageclasses"]

    verbs: ["get", "list", "watch"]

  - apiGroups: [""]

    resources: ["events"]

    verbs: ["create", "update", "patch"]

---

kind: ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: run-nfs-client-provisioner

subjects:

  - kind: ServiceAccount

    name: nfs-client-provisioner

    namespace: default

roleRef:

  kind: ClusterRole

  name: nfs-client-provisioner-runner

  apiGroup: rbac.authorization.k8s.io

---

kind: Role

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: leader-locking-nfs-client-provisioner

  namespace: default

rules:

  - apiGroups: [""]

    resources: ["endpoints"]

    verbs: ["get", "list", "watch", "create", "update", "patch"]

---

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: leader-locking-nfs-client-provisioner

  namespace: default

subjects:

  - kind: ServiceAccount

    name: nfs-client-provisioner

    namespace: default

roleRef:

  kind: Role

  name: leader-locking-nfs-client-provisioner

  apiGroup: rbac.authorization.k8s.io

测试动态供应

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: nginx-pvc

  namespace: default

  labels:

    app: nginx-pvc

spec:

  storageClassName: nfs-client # 注意此处

  accessModes:

  - ReadWriteOnce

  resources:

    requests:

      storage: 2Gi

---

apiVersion: v1

kind: Pod

metadata:

  name: nginx

  namespace: default

  labels:

    app: nginx

spec:

  containers:

  - name: nginx

    image: nginx:1.20.2

    resources:

      limits:

        cpu: 200m

        memory: 500Mi

      requests:

        cpu: 100m

        memory: 200Mi

    ports:

    - containerPort:  80

      name:  http

    volumeMounts:

    - name: localtime

      mountPath: /etc/localtime

    - name: html

      mountPath: /usr/share/nginx/html/

  volumes:

    - name: localtime

      hostPath:

        path: /usr/share/zoneinfo/Asia/Shanghai

    - name: html   

      persistentVolumeClaim:

        claimName:  nginx-pvc

        readOnly: false 

  restartPolicy: Always

设置 SC 为默认驱动

kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

kubectl patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: nginx-pvc

  namespace: default

  labels:

    app: nginx-pvc

spec:

  # storageClassName: nfs-client 不写，就使用默认的

  accessModes:

  - ReadWriteOnce

  resources:

    requests:

      storage: 2Gi

---

apiVersion: v1

kind: Pod

metadata:

  name: nginx

  namespace: default

  labels:

    app: nginx

spec:

  containers:

  - name: nginx

    image: nginx:1.20.2

    resources:

      limits:

        cpu: 200m

        memory: 500Mi

      requests:

        cpu: 100m

        memory: 200Mi

    ports:

    - containerPort:  80

      name:  http

    volumeMounts:

    - name: localtime

      mountPath: /etc/localtime

    - name: html

      mountPath: /usr/share/nginx/html/

  volumes:

    - name: localtime

      hostPath:

        path: /usr/share/zoneinfo/Asia/Shanghai

    - name: html   

      persistentVolumeClaim:

        claimName:  nginx-pvc

        readOnly: false 

  restartPolicy: Always

展望

目前，只需要运维人员部署好各种 storageclass，开发人员在使用的时候，创建 PVC 即可；但是，存储系统太多太多，运维人员也未必会一一掌握，此时就需要 Rook 来统一管理了。

特殊存储卷

ConfigMap

ConfigMap是一个比较特殊的存储卷，它的主要作用是用来存储配置信息的

创建configmap

apiVersion: v1

kind: ConfigMap

metadata:

  name: configmap-test

  namespace: study

data: # 下面都是要存储的数据

  info: # 会创建一个名为info文件，文件内容如下

    username:admin

    password:123456

# 如果更新ConfigMap中的内容，容器中的值也会动态更新

# 更改后重新 apply 或 使用 edit命令

# 注意：需要一定时间

[root@master k8s]# kubectl apply  -f configmap.yaml

configmap/configmap-test created

[root@master k8s]# kubectl get cm -n study

NAME               DATA   AGE

configmap-test     1      22s

kube-root-ca.crt   1      4d21h

创建pod挂载configmap

apiVersion: v1

kind: Pod

metadata:

  name: pod-configmap

  namespace: study

spec:

  containers:

    - name: nginx

      image: nginx:1.17.1

      volumeMounts:

        - mountPath: /configmap/config

          name: config

  volumes:

    - name: config

      configMap:

        name: configmap-test # 绑定 configmap

[root@master k8s]# kubectl apply -f configmap.yaml

pod/pod-configmap created

[root@master k8s]# kubectl get pod -n study

NAME            READY   STATUS    RESTARTS   AGE

pod-configmap   1/1     Running   0          11s

[root@master k8s]# kubectl exec -it -n study pod-configmap -c nginx /bin/sh
# ls /configmap/config

info

# cat /configmap/config/info

username:admin password:123456

Secret

在kubernetes中，还存在一种和ConfigMap非常类似的对象，称为Secret对象，它主要用来存储敏感信息，例如密码、密钥、证书等等

Secret 是一个用于存储敏感数据的资源，所有的数据要经过base64编码，数据实际会存储在K8s中Etcd,然后通过创建Pod时引用该数据。

查询 Secret 的时候是加密，在pod容器里面显示的是解密后的内容

Pod 使用 secret 数据有两种方式：

变量注入
数据卷挂载

kubectl create secret 支持三种数据类型：

docker--registry:存储镜像仓库认证信息
generic:从文件、目录或者字符串创建，例如存储用户名密码
ts:存储证书，例如HTTPS证书

type字段

内置类型	用法
Opaque	用户定义的任意数据
kubernetes.io/service-account-token	服务账号令牌
kubernetes.io/dockercfg	~/.dockercfg 文件的序列化形式
kubernetes.io/dockerconfigjson	~/.docker/config.json 文件的序列化形式
kubernetes.io/basic-auth	用于基本身份认证的凭据
kubernetes.io/ssh-auth	用于 SSH 身份认证的凭据
kubernetes.io/tls	用于 TLS 客户端或者服务器端的数据
bootstrap.kubernetes.io/token	启动引导令牌数据

yaml 解析

# 准备base64加密数据

echo -n "admin" | base64

echo -n "123456" | base64

apiVersion: v1

kind: Secret

metadata:

  name: secret

  namespace: dev

type: Opaque

data: # 下面存存储敏感信息，已base64加密

  # 这里 username 是一个文件名，这里 password 是一个文件名

  username: YWRtaW4=

  password: MTIzNDU2

  # mysql-root-password:"MTIzNDU2"

stringData: #如果不手动进行编码加密，可以将这个操作让k8s来做，使用stringdata

  username: admin

  password: "123456"

# 不能直接写数字，不然会报错 cannot convert int64 to string,如果要写数字就加""

注：如果同时使用data和stringData，那么data会被忽略

[root@master k8s]# kubectl apply -f secret.yaml

secret/secret created

[root@master k8s]# kubectl describe secrets -n study

Name:         secret

Namespace:    study

Labels:       <none>

Annotations:  <none>



Type:  Opaque



Data

====

password:  6 bytes

username:  5 bytes

数据卷挂载

apiVersion: v1

kind: Pod

metadata:

  name: pod-secret

  namespace: study

spec:

  containers:

    - name: nginx

      image: nginx:1.17.1

      volumeMounts:

        - mountPath: /secret/config

          name: secret-config

  volumes:

    - name: secret-config

      secret:

        secretName: secret

kubectl exec -it -n study pod-secret -c nginx /bin/sh

# cat /secret/config/password

123456

解码 Secret

kubectl get secret db-user-pass -o jsonpath='{.data}' | base64

变量注入

示例：将Mysql用户密码保存到Secret中存储

[root@master cks]# echo -n "123456" | base64

MTIzNDU2

apiVersion: v1

kind: Secret

metadata:

  name: mysql

type: Opaque

data:

  mysql-root-password: "MTIzNDU2"

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: mysql

spec:

  selector:

    matchLabels:

      app: mysql

  template:

    metadata:

      labels:

        app: mysql

    spec:

      containers:

      - name: mysql-db

        image: mysql:5.7.30

        env:

        - name: MYSQL_ROOT_PASSWORD

          valueFrom:

            secretKeyRef:

              name: mysql

              key: mysql-root-password

将 secret 的mysql中的mysql-root-passwd变量注入到容器中的 MYSQL_ROOT_PASSWORD 变量

[root@master cks]# kubectl exec -it mysql-6c8b6c4d74-vbflz /bin/sh

# mysql -uroot -p123456

mysql: [Warning] Using a password on the command line interface can be insecure.

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 4

Server version: 5.7.30 MySQL Community Server (GPL)



Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.



Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.



Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.



mysql>

镜像拉取密码

imagePullSecret：Pod拉取私有镜像仓库的时使用的账户密码，会传递给kubelet，然后kubelet就可以拉取有密码的仓库里面的镜像

kubectl create secret docker-registry docker-harbor-registrykey --docker-server=192.168.18.119:85 \

          --docker-username=admin --docker-password=Harbor12345 \

          --docker-email=1900919313@qq.com

apiVersion: v1

kind: Pod

metadata:

  name: redis

spec:

  containers:

    - name: redis

      image: 192.168.18.119:85/yuncloud/redis # 这是Harbor的镜像私有仓库地址

  imagePullSecrets:

    - name: docker-harbor-registrykey

总结以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。