PV、PVC

前言一、 存储卷1. emptyDir 存储卷1.1 概念1.2 实例

2. hostPath 存储卷2.1 概念2.2 实例

3. nfs共享存储卷

二、PV 和 PVC1. 概念1.1 PV1.2 PVC1.3 PVC 的使用逻辑1.4 创建机制1.5 PV 和 PVC 的生命力周期1.6 创建及销毁 PV 的流程

2. PV 和 PVC 的创建2.1 查看定义2.2 NFS 创建静态PV1) 配置nfs存储2) 定义 PV3) 定义 PVC4) 测试访问

2.3 搭建 StorageClass + nfs-client-provisioner ，实现 NFS 的动态 PV 创建1) 配置nfs服务2) 创建 Service Account3) 使用 Deployment 来创建 NFS Provisioner4) 创建 StorageClass5) 创建 PVC 和 Pod 测试

总结1. 常使用的日志分析工具有些哪些以及它们如何与K8S集群进行通信2. K8S 的存储卷3. PV 和 PVC4. 创建 PV 的方式（PV类型）5. PV 的四种状态6. 创建 PV 资源

前言

  容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动。其次，在Pod中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的Volume抽象就很好的解决了这些问题。Pod中的容器通过Pause容器共享Volume。

一、 存储卷

1. emptyDir 存储卷

1.1 概念

  当Pod被分配给节点时，首先创建emptyDir卷，并且只要该Pod在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。Pod 中的容器可以读取和写入emptyDir卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时，emptyDir中的数据将被永久删除。

1.2 实例

mkdir /opt/volumes

cd /opt/volumes

vim pod-emptydir.yaml

apiVersion: v1

kind: Pod

metadata:

name: pod-emptydir

namespace: default

labels:

app: myapp

tier: frontend

spec:

containers:

- name: myapp

image: ikubernetes/myapp:v1

imagePullPolicy: IfNotPresent

ports:

- name: http

containerPort: 80

#定义容器挂载内容

volumeMounts:

#使用的存储卷名称，如果跟下面volume字段name值相同，则表示使用volume的这个存储卷

- name: html

#挂载至容器中哪个目录

mountPath: /usr/share/nginx/html/

- name: busybox

image: busybox:latest

imagePullPolicy: IfNotPresent

volumeMounts:

- name: html

#在容器内定义挂载存储名称和挂载路径

mountPath: /data/

command: ['/bin/sh','-c','while true;do echo $(date) >> /data/index.html;sleep 2;done']

#定义存储卷

volumes:

#定义存储卷名称

- name: html

#定义存储卷类型

emptyDir: {}

kubectl apply -f pod-emptydir.yaml

kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES

pod-emptydir 2/2 Running 0 49s 10.244.1.9 node01

#在上面定义了2个容器，其中一个容器是输入日期到index.html中，然后验证访问nginx的html是否可以获取日期。以验证两个容器之间挂载的emptyDir实现共享。

curl 10.244.1.9

Fri Aug 11 07:19:57 UTC 2023

Fri Aug 11 07:19:59 UTC 2023

Fri Aug 11 07:20:01 UTC 2023

Fri Aug 11 07:20:03 UTC 2023

Fri Aug 11 07:20:05 UTC 2023

Fri Aug 11 07:20:07 UTC 2023

Fri Aug 11 07:20:09 UTC 2023

Fri Aug 11 07:20:11 UTC 2023

Fri Aug 11 07:20:13 UTC 2023

Fri Aug 11 07:20:15 UTC 2023

Fri Aug 11 07:20:17 UTC 2023

Fri Aug 11 07:20:19 UTC 2023

Fri Aug 11 07:20:21 UTC 2023

Fri Aug 11 07:20:23 UTC 2023

Fri Aug 11 07:20:25 UTC 2023

Fri Aug 11 07:20:27 UTC 2023

Fri Aug 11 07:20:29 UTC 2023

Fri Aug 11 07:20:31 UTC 2023

Fri Aug 11 07:20:33 UTC 2023

Fri Aug 11 07:20:35 UTC 2023

Fri Aug 11 07:20:37 UTC 2023

Fri Aug 11 07:20:39 UTC 2023

Fri Aug 11 07:20:41 UTC 2023

Fri Aug 11 07:20:43 UTC 2023

Fri Aug 11 07:20:45 UTC 2023

Fri Aug 11 07:20:47 UTC 2023

2. hostPath 存储卷

2.1 概念

  hostPath卷将 node 节点的文件系统中的文件或目录挂载到集群中。

  hostPath可以实现持久存储，但是在node节点故障时，也会导致数据的丢失。

2.2 实例

#在 node01 节点上创建挂载目录

mkdir -p /data/pod/volume1

echo 'node01.abc.com' > /data/pod/volume1/index.html

#创建 Pod 资源

vim pod-hostpath.yaml

apiVersion: v1

kind: Pod

metadata:

name: pod-hostpath

namespace: default

spec:

containers:

- name: myapp

image: nginx

#定义容器挂载内容

volumeMounts:

#使用的存储卷名称，如果跟下面volume字段name值相同，则表示使用volume的这个存储卷

- name: html

#挂载至容器中哪个目录

mountPath: /usr/share/nginx/html

#读写挂载方式，默认为读写模式false

readOnly: false

#volumes字段定义了paues容器关联的宿主机或分布式文件系统存储卷

volumes:

#存储卷名称

- name: html

#路径，为宿主机存储路径

hostPath:

#在宿主机上目录的路径

path: /data/pod/volume1

#定义类型，这表示如果宿主机没有此目录则会自动创建

type: DirectoryOrCreate

kubectl apply -f pod-hostpath.yaml

#访问测试

kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES

pod-hostpath 1/1 Running 0 25s 10.244.1.12 node01

curl 10.244.1.12

node01.abc.com

#删除pod，再重建，验证是否依旧可以访问原来的内容

kubectl delete -f pod-hostpath.yaml

kubectl apply -f pod-hostpath.yaml

kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES

pod-hostpath 1/1 Running 0 31s 10.244.1.13 node01

curl 10.244.1.13

node01.abc.com

3. nfs共享存储卷

#在stor01节点上环境配置

hostnamectl set-hostname stor01

systemctl stop firewalld

setenforce 0

rpm -q rpcbind

rpm -q nfs-utils

#在stor01节点上安装nfs，并配置nfs服务

mkdir /data/volumes -p

chmod 777 /data/volumes

vim /etc/exports

/data/volumes 192.168.145.0/24(rw,no_root_squash)

systemctl start rpcbind

systemctl start nfs

showmount -e

Export list for stor01:

/data/volumes 192.168.145.0/24

#master节点操作

vim pod-nfs-vol.yaml

apiVersion: v1

kind: Pod

metadata:

name: pod-vol-nfs

namespace: default

spec:

containers:

- name: myapp

image: ikubernetes/myapp:v1

volumeMounts:

- name: html

mountPath: /usr/share/nginx/html

volumes:

- name: html

nfs:

path: /data/volumes

server: stor01

kubectl apply -f pod-nfs-vol.yaml

kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES

pod-vol-nfs 1/1 Running 0 113s 10.244.1.14 node01

#在nfs服务器上创建index.html

cd /data/volumes

vim index.html

nfs stor01

#master节点操作

curl 10.244.1.14

nfs stor01

kubectl delete -f pod-nfs-vol.yaml #删除nfs相关pod，再重新创建，可以得到数据的持久化存储

kubectl apply -f pod-nfs-vol.yaml

二、PV 和 PVC

1. 概念

1.1 PV

  PV 全称叫做 Persistent Volume，持久化存储卷。它是用来描述或者说用来定义一个存储卷的，这个通常都是由运维工程师来定义。

1.2 PVC

  PVC 的全称是 Persistent Volume Claim，是持久化存储的请求。它是用来描述希望使用什么样的或者说是满足什么条件的 PV 存储。

1.3 PVC 的使用逻辑

  在 Pod 中定义一个存储卷（该存储卷类型为 PVC），定义的时候直接指定大小，PVC 必须与对应的 PV 建立关系，PVC 会根据配置的定义去 PV 申请，而 PV 是由存储空间创建出来的。PV 和 PVC 是 Kubernetes 抽象出来的一种存储资源。

1.4 创建机制

  PV和PVC模式是需要运维人员先创建好PV，然后开发人员定义好PVC进行一对一的Bond，但是如果PVC请求成千上万，那么就需要创建成千上万的PV，对于运维人员来说维护成本很高，Kubernetes提供一种自动创建PV的机制，叫StorageClass，它的作用就是创建PV的模板。

  创建 StorageClass 需要定义 PV 的属性，比如存储类型、大小等；另外创建这种 PV 需要用到的存储插件，比如 Ceph 等。 有了这两部分信息，Kubernetes 就能够根据用户提交的 PVC，找到对应的 StorageClass，然后 Kubernetes 就会调用 StorageClass 声明的存储插件，自动创建需要的 PV 并进行绑定。

  总结：PV是集群中的资源。 PVC是对这些资源的请求，也是对资源的索引检查。

1.5 PV 和 PVC 的生命力周期

PV和PVC之间的相互作用遵循这个生命周期：

Provisioning（配置）—> Binding（绑定）—> Using（使用）—> Releasing（释放） —> Recycling（回收）

Provisioning，即 PV 的创建，可以直接创建 PV（静态方式），也可以使用 StorageClass 动态创建

Binding，将 PV 分配给 PVC

Using，Pod 通过 PVC 使用该 Volume，并可以通过准入控制StorageProtection（1.9及以前版本为PVCProtection） 阻止删除正在使用的 PVC

Releasing，Pod 释放 Volume 并删除 PVC

Reclaiming，回收 PV，可以保留 PV 以便下次使用，也可以直接从云存储中删除

  根据这 5 个阶段，PV 的状态有以下 4 种：

Available（可用）：表示可用状态，还未被任何 PVC 绑定

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

Released（已释放）：表示 PVC 被删掉，但是资源尚未被集群回收

Failed（失败）：表示该 PV 的自动回收失败

1.6 创建及销毁 PV 的流程

  一个PV从创建到销毁的具体流程如下：

一个PV创建完后状态会变成Available，等待被PVC绑定。一旦被PVC邦定，PV的状态会变成Bound，就可以被定义了相应PVC的Pod使用。Pod使用完后会释放PV，PV的状态变成Released。变成Released的PV会根据定义的回收策略做相应的回收工作。

回收策略作用RetainRetain就是保留现场，K8S集群什么也不做，等待用户手动去处理PV里的数据，处理完后，再手动删除PV。DeleteDelete策略，K8S会自动删除该PV及里面的数据。RecycleRecycle方式，K8S会将PV里的数据删除，然后把PV的状态变成Available，又可以被新的PVC绑定使用。

2. PV 和 PVC 的创建

2.1 查看定义

kubectl explain pv.spec #查看pv定义的规格

FIELDS:

apiVersion: v1

kind: PersistentVolume

metadata: #由于 PV 是集群级别的资源，即 PV 可以跨 namespace 使用，所以 PV 的 metadata 中不用配置 namespace

name:

spec

kubectl explain pv.spec #查看pv定义的规格

spec:

nfs:（定义存储类型）

path:（定义挂载卷路径）

server:（定义服务器名称）

accessModes:（定义访问模型，有以下三种访问模型，以列表的方式存在，也就是说可以定义多个访问模式）

- ReadWriteOnce #（RWO）卷可以被一个节点以读写方式挂载。 ReadWriteOnce 访问模式也允许运行在同一节点上的多个 Pod 访问卷。

- ReadOnlyMany #（ROX）卷可以被多个节点以只读方式挂载。

- ReadWriteMany #（RWX）卷可以被多个节点以读写方式挂载。

#nfs 支持全部三种；iSCSI 不支持 ReadWriteMany（iSCSI 就是在 IP 网络上运行 SCSI 协议的一种网络存储技术）；HostPath 不支持 ReadOnlyMany 和 ReadWriteMany。

capacity:（定义存储能力，一般用于设置存储空间）

storage: 2Gi （指定大小）

storageClassName: （自定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）

persistentVolumeReclaimPolicy: Retain #回收策略（Retain/Delete/Recycle）

---------------------------------------------------------------------------------------------------------------------------

#Retain（保留）：当用户删除与之绑定的PVC时候，这个PV被标记为released（PVC与PV解绑但还没有执行回收策略）且之前的数据依然保存在该PV上，但是该PV不可用，需要手动来处理这些数据并删除该PV。

#Delete（删除）：删除与PV相连的后端存储资源。对于动态配置的PV来说，默认回收策略为Delete。表示当用户删除对应的PVC时，动态配置的volume将被自动删除。（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）

#Recycle（回收）：如果用户删除PVC，则删除卷上的数据，卷不会删除。（只有 NFS 和 HostPath 支持）

kubectl explain pvc #查看PVC的定义方式

KIND: PersistentVolumeClaim

VERSION: v1

FIELDS:

apiVersion

kind

metadata