k8s存储卷 +PVC和PV（听到收音机里放歌，叫《一生所爱》。）

emptyDir存储卷

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

mkdir shiyan
cd /shiyan
vim pod4.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx1
    image: nginx
    ports:
    - name: http
      containerPort: 80
    volumeMounts:                                                     #定义容器挂载内容
    - name: html                                    #使用存储卷名称，如果跟下面volume字段name值相同，则表示使用volume的这个存储卷
      mountPath: /usr/share/nginx/html/                              #挂载至容器中哪个目录
  - name: nginx2
    image: nginx
    volumeMounts:
    - name: html
      mountPath: /data/
    command: ['/bin/bash','-c','while true;do echo $(date) >> /data/index.html;sleep 2;done']
  volumes:
  - name: html
    emptyDir: {}

kubectl exec -it nginx -c nginx2 sh                                 #-c指定pod里面的容器名进入

 

 

 

 

hostPath存储卷

hostPath卷将 node 节点的文件系统中的文件或目录挂载到集群中。
hostPath可以实现持久存储，但是在node节点故障时，也会导致数据的丢失。

在 node01 节点上创建挂载目录
mkdir -p /data/pod/
echo 'node1.com' > /data/pod/index.html

在 node02 节点上创建挂载目录
mkdir -p /data/pod/
echo 'node2.com' > /data/pod/index.html

创建 Pod 资源
vim pod5.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:                                           #定义容器挂载内容
    - name: html                                               #使用存储卷名称于volume定义 的name相同
      mountPath: /usr/share/nginx/html/      #定义容器内的挂载目录
      readOnly: false                                         #读写挂载方式，默认为读写模式false             
  volumes: 
    - name: html                                               #定义存储卷名称
      hostPath:                                                   #路径，宿主机存储路径
        path: /data/pod/                                    #在宿主机上目录的路径
        type: DirectoryOrCreate                        #定义类型，如果宿主机没有此目录会自动创建
kubectl get pods -o wide

curl 10.244.2.6                                               #删除pod重建文件内容依然存在，直接修改主机内的目录也可以

 

nfs共享存储卷

在新节点（node3）安装nfs并配置服务
mkdir /data/pod -p
chmod 777 /data/pod/
echo 'node3' > /data/pod/index.html

vim /etc/exports
/data/pod 192.168.150.0/24(rw,no_root_squash)
                                         
systemctl start rpcbind
systemctl start nfs

showmount -e
Export list for localhost.localdomain:
/data/pod 192.168.150.0/24

master节点操作，k8s集群需要添加主机名映射
vim pod6.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html/
  volumes:
    - name: html
      nfs:                                                            #指定挂载类型为nfs
        path: /data/pod/                                         
        server: stor03                                     #指定nfs服务器名，只能是主机名不能为IP地址

 

 

PVC和 PV

PersistentVolume（PV）是集群中已由管理员配置的一段网络存储。集群中的资源就像一个节点是一个集群资源。

PV是诸如卷之类的卷插件，但是具有独立于使用PV的任何单个pod的生命周期。

该API对象捕获存储的实现细节，即NFS、iSCSI或云提供商特定的存储系统。

 

PersistentVolumeclaim（PVC）是用户存储的请求。PVC的使用逻辑∶在pod中定义一个存储卷（该存储卷类型为PVC），定义的时候直接指定大小，pvc必须与对应的pv建立关系，pvc会根据定义去pv申请，而pv是由存储空间创建出来的。pv和pvc是kubernetes抽象出来的一种存储资源。

 

虽然PersistentVolumeClaims允许用户使用抽象存储资源，但是常见的需求是，用户需要根据不同的需求去创建PV，用于不同的场景。而此时需要集群管理员提供不同需求的PV，而不仅仅是PV的大小和访问模式，但又不需要用户了解这些卷的实现细节。对于这样的需求，此时可以采用StorageClass资源（动态）。

 

PV是集群中的资源。 PVC是对这些资源的请求，也是对资源的索引检查。PV和PVC之间的相互作用遵循这个生命周期∶

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

 

这里有两种PV的提供方式∶静态或者动态

静态-->直接固定存储空间∶

集群管理员创建一些 PV。它们携带可供集群用户使用的真实存储的详细信息。它们存在于Kubernetes API中，可用于消费。

 

动态-->通过存储类进行动态创建存储空间∶

当管理员创建的静态 PV 都不匹配用户的PVC时，集群可能会尝试动态地为 PVC 配置卷。此配置基于 storageClasses: PVC必须请求存储类，并且管理员必须已创建并配置该类才能进行动态配置。要求该类的声明有效地为自已禁用动态配置。

格式

kubectl explain pv                                   #查看pv的定义方式
FIELDS:
    apiVersion 
    kind 
    metadata 
    spec

kubectl explain pv.spec                               #查看pv定义的规格
spec:
  nfs（定义存储类型）
    path（定义挂载卷路径）
    server（定义服务器名称）
  accessModes（定义访问模型，有以下三种访问模型，以列表的方式存在，也就是说可以定义多个访
问模式）
ReadWriteOnce（RWO） 单节点读写    
ReadOnlyMany（ROX）多节点只读    
ReadWriteMany（RWX）多节点读写
  persistentVolumeReclaimPolicy: Retain               #可以定义回收策略
  capacity（定义PV空间的大小）
    storage（指定大小）
kubectl explain pvc                                  #查看PVC的定义方式
KIND: PersistentVolumeClaim
VERSION: v1 
FIELDS:
   apiVersion <string>
   kind <string>
   metadata <Object>
   spec <Object>

kubectl explain pvc.spec 
spec:
  accessModes（定义访问模式，必须是P的访问模式的子集）
  resources （定义申请资源的大小）
requests:       
storage:

 

NFS使用PV和PVC

 

1、单独一台机器配置nfs存储

mkdir -p /data/v{1,2,3,4,5}
chmod 777 /data/v{1,2,3,4,5}

vim /etc/exports
/data/v1 192.168.10.0/24(rw,no_root_squash)
/data/v2 192.168.10.0/24(rw,no_root_squash)
/data/v3 192.168.10.0/24(rw,no_root_squash)
/data/v4 192.168.10.0/24(rw,no_root_squash)
/data/v5 192.168.10.0/24(rw,no_root_squash)
exportfs -arv 
showmount -e

 

 

 

这里定义5个PV，并且定义挂载的路径以及访问模式，还有PV划分的大小。

vim pv.yaml

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv01

  labels:

    name: pv01

spec:

  nfs:

    path: /data/v1

    server: nfs01

  accessModes: ["ReadWriteMany","ReadWriteOnce"]

  capacity:

    storage: 1Gi

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv02

  labels:

    name: pv02

spec:

  nfs:

    path: /data/v2

    server: nfs01

  accessModes: ["ReadWriteOnce"]

  capacity:

    storage: 2Gi

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv03

  labels:

    name: pv03

spec:

  nfs:

    path: /data/v3

    server: nfs01

  accessModes: ["ReadWriteMany","ReadWriteOnce"]

  capacity:

    storage: 2Gi

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv04

  labels:

    name: pv04

spec:

  nfs:

    path: /data/v4

    server: nfs01

  accessModes: ["ReadWriteMany","ReadWriteOnce"]

  capacity:

    storage: 4Gi

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pv05

  labels:

    name: pv05

spec:

  nfs:

    path: /data/v5

    server: nfs01

  accessModes: ["ReadWriteMany","ReadWriteOnce"]

  capacity:

    storage: 5Gi

 

kubectl create -f pv.yaml

 

kubectl get pv

 

这里定义了pvc的访问模式为多路读写，该访问模式必须在前面pv定义的访问模式之中。定义PVc申请的大小为2Gi，此时PVC会自动去匹配多路读写且大小为2Gi的PV，匹配成功获取PVC的状态即为Bound（需要做好node节点和nfs服务器的映射）
vim pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginxpvc
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx01
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
    - name: html
      persistentVolumeClaim:
        claimName: nginxpvc

 

StorageClass

 

在pv和pvc使用过程中存在的问题，在pvc申请存储空间时，未必就有现成的py符合pvc申请的需求，上面nfs在做pvc可以成功的因素是因为我们做了指定的需求处理。那么当PvC申请的存储空间不一定有满足PVC要求的PV时，又该如何处理呢为此，Kubernetes为管理员提供了描述存储"class（类）"的方法（storageClass）。举个例子，在存储系统中划分一个1TB的存储空间提供给Kubernetes使用，当用户需要一个10G的pvc时，会立即通过restful发送请求，从而让存储空间创建一个10G的image，之后在我们的集群中定义成10G的Pv供给给当前的PVC作为挂载使用。在此之前我们的存储系统必须支持restful接口，比如ceph分布式存储，而glusterfs则需要借助第三方接口完成这样的请求。

 

kubectl explapin storageclass                           #storageclass也是k8s上的资源
KIND:     StorageClass
VERSION:  storage.k8s.io/v1
FIELDS:
  allowVolumeExpansion <boolean>
  allowedTopologies    <[]Object>
  apiVersion           <string>
  kind                 <string>
  metadata             <Object>
  mountOptions         <[]string>           #挂载选项
  parameters           <map[string]string>   #参数，取决于分配器，可以接受不同的参数。例如参数 type 的值 iol 和参数 iopsPerGB 特定于EBS PV。当参数被省略时，会使用默认值。
  provisioner          <string>-required-      #存储分配器，用来决定使用哪个卷插件分配 PV。该字段必须指定。
  reclaimPolicy        <string>              #回收策略，可以是 Delete 或者 Retain。如果 storageclass 对象被创建时没有指定 reclaimPolicy，它将
默认为 Delete。
  volumeBindingMode   <string>   #卷的绑定模式