【云原生--Kubernetes】PV、PVC

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

一. PV和PVC

1.1 PV 概念

1. PersistentVolume(PV) 是集群中由管理员配置的一段网络存储。集群中的资源就像一个节点是一个集群资源，可以从远程的NFS 或分布式对象存储系统中创建得来（PV 存储空间大小、访问方式）。
2. PV 是诸如卷之类的卷插件，但是只有独立于使用 PV 的任何单个 pod 的生命周期。
3. 该 API 对象捕获存储的实现细节，即 NFS，ISCSI 或云提供商特定的存储系统。
4. PV 就是从存储设备中的空间创建出一个存储资源。

1.2 PVC 概念

1. PersistentVolumeClaim(PVC) 是用户存储的请求。PVC 的使用逻辑：在 pod 中定义一个存储卷（该存储卷类型为PVC)，定义的时候直按指定大小，PVC 必须与对应的 PV 建立关系，PVC 会根据定义去 PV 申请，而 PV是由存储空间创建出来的。PV 和 PVC 是 kubernetes 抽象出来的一种存储资源。
2. 虽然 PersistentVolumeClaims 允许用户使用抽象存储资源，但是常见的需求是，用户需要根据不同的需求去创建PV，用于不同的场景。而此时需要集群管理员提供不同需求的 PV，而不仅仅是 PV 的大小和访问模式，但又不需要用户了解这些卷的实现细节。
3. 对于这样的需求，此时可以采用 storageclass 资源。

1.3 PV 与 PVC

• PV 与 PVC 之间的关系
  PV 是集群中的资源，PVC 是对这些资源的请求，也是对资源的索引检查。
• 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
• Recycling，回收 PV，可以保留 PV 以便下次使用，也可以直接从云存储中删除
  根据这 5 个阶段，PV 的状态有以下 4 种：
• Available（可用）：表示可用状态，还未被任何 PVC 绑定
• Bound（已绑定）：表示 PV 已经绑定到 PVC
• Released（已释放）：表示 PVC 被删掉，但是资源尚未被集群回收
• Failed（失败）：表示该 PV 的自动回收失败

1.4 PV 创建流程

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

1.5 回收策略

有三种回收策略，Retain、Delete和Recycle。

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

1.6 PV、PVC定义方式

查看pv的定义方式
kubectl explain pv

FIELDS:
	apiVersion: v1
	kind: PersistentVolume
	metadata:    #由于 PV 是集群级别的资源，即 PV 可以跨 namespace 使用，所以 PV 的 metadata 中不用配置 namespace
	  name: 
	spec

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

spec:
  nfs:（定义存储类型）
    path:（定义挂载卷路径）
    server:（定义服务器名称）
  accessModes:（定义访问模型，有以下三种访问模型，以列表的方式存在，也就是说可以定义多个访问模式）
    - ReadWriteOnce          #（RWO）存储可读可写，但只支持被单个 Pod 挂载
	- ReadOnlyMany           #（ROX）存储可以以只读的方式被多个 Pod 挂载
	- ReadWriteMany          #（RWX）存储可以以读写的方式被多个 Pod 共享
#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相连的后端存储资源（只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持）
#Recycle（回收）：删除数据，效果相当于执行了 rm -rf /thevolume/* （只有 NFS 和 HostPath 支持）

查看PVC的定义方式
kubectl explain pvc

KIND:     PersistentVolumeClaim
VERSION:  v1
FIELDS:
   apiVersion	<string>
   kind	<string>  
   metadata	<Object>
   spec	<Object>

PV和PVC中的spec关键字段要匹配，比如存储（storage）大小、访问模式（accessModes）、存储类名称（storageClassName）

kubectl explain pvc.spec
spec:
  accessModes: （定义访问模式，必须是PV的访问模式的子集）
  resources:
    requests:
      storage: （定义申请资源的大小）
  storageClassName: （定义存储类名称，此配置用于绑定具有相同类别的PVC和PV）

1.7 PV的提供方式

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

• 静态 —》直接固定存储空间
  集群管理员创建一些 PV。它们携带可供集群用户使用的真实存储的详细信息。它们存在于 Kubernetes API 中，可用于消费。
• 动态 —》通过存储类进行动态创建存储空间
  当管理员创建的静态 PV 都不匹配用户的 PVC 时，集群可能会尝试动态地为 PVC 配置卷。此配置基于
  StorageClasses：PVC必须请求存储类，并且管理员必须已创建并配置该类才能进行动态配置。要求该类的声明有效地为自己禁用动态配置。

二. 基于NFS创建静态 PV、PVC

试验环境

nfs-server	k8s-master（192.168.48.14）
nfs-client	k8s-node1（192.168.48.13），k8s-node2（192.168.48.11）

2.1 NFS服务部署

• 所有节点安装nfs

yum install -y nfs-utils rpcbind

以下操作均在NFS服务器上操作

• 创建共享目录，并授权

mkdir /nfsdata1
mkdir /nfsdata2
mkdir /nfsdata3

chmod 777 /nfsdata1
chmod 777 /nfsdata2
chmod 777 /nfsdata3

• 配置权限
  编辑 exports 文件

vim /etc/exports
/nfsdata1 192.168.48.0/24(rw,no_root_squash,sync)
/nfsdata2 192.168.48.0/24(rw,no_root_squash,sync)
/nfsdata3 192.168.48.0/24(rw,no_root_squash,sync)

exportfs -rv

• 所有服务器启动NFS服务

#手动加载 NFS 共享服务时，应该先启动 rpcbind，再启动 nfs
systemctl start rpcbind && systemctl enable rpcbind
systemctl start nfs && systemctl enable nfs
#查看 rpcbind 端口是否开启，rpcbind 服务默认使用 tcp 端口 111
netstat -anpt | grep rpcbind

查看本机发布的共享目录

showmount -e

• 创建访问页面供测试用

echo '11111' > /nfsdata1/index.html
echo '22222' > /nfsdata2/index.html
echo '33333' > /nfsdata3/index.html

2.2 创建PV

• 创建PV
  定义 3 个 PV，并且定义挂载的路径以及访问模式，还有 PV 划分的大小。
  vim pv-demo.yaml
  注意自己的共享目录和主机IP

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /nfsdata1
    server: 192.168.48.14
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /nfsdata2
    server: 192.168.48.14
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /nfsdata3
    server: 192.168.48.14
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi

创建并查看

kubectl apply -f pv-demo.yaml 
kubectl get pv

2.3 定义PVC

• 定义PVC
  这里定义了 PVC 的访问模式为多路读写，该访问模式必须在前面 PV 定义的访问模式之中。定义 PVC 申请的大小为 2Gi，此时 PVC 会自动去匹配多路读写且大小为 2Gi 的 PV ，匹配成功获取 PVC 的状态即为 Bound。

vim pvc-demo.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pv-pvc
spec:
  containers:
  - name: myapp
    image: nginx
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html
    persistentVolumeClaim:
      claimName: mypvc

发布并查看

kubectl apply -f pvc-demo.yaml
kubectl get pvc

可以看到 pv003 设定的 pvc 请求存储卷是 2Gi 并且多路可读可写。
访问 pv003

kubectl get pod -o wide
curl 10.150.1.127

2.4 多路读写测试

1. 我们通过相同的存储卷，只修改 pod 的名称
cp pvc-demo.yaml 1.yaml
cp pvc-demo.yaml 2.yaml
2. 修改 pod 的名称后，apply 执行创建
kubectl apply -f 1.yaml
kubectl apply -f 2.yaml
3. 查看 ip
kubectl get pod -o wide 
4. curl 进行测试，查看是否共享存储卷，多路读写

三. 基于动态 storageclass 创建 PV、PVC

3.1 storageclass 定义

前面的例子中，我们提前创建了 PV，然后通过 PVC 申请 PV 并在 Pod 中使用，这种方式叫做静态供给（Static Provision）。
与之对应的是动态供给（Dynamical Provision），即如果没有满足 PVC 条件的 PV，会动态创建 PV。相比静态供给，动态供给有明显的优势：不需要提前创建 PV，减少了管理员的工作量，效率高。

3.2 storageclass 用途

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

3.3 基于NFS动态创建PV、PVC

Kubernetes支持动态供给的存储插件：https://kubernetes.io/docs/concepts/storage/storage-classes/

因为NFS不支持动态存储，所以我们需要借用这个存储插件。
nfs动态相关部署可以参考：https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy

• 定义一个storageclass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storage
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  archiveOnDelete: "true"  ## 删除pv的时候，pv的内容是否要备份

• 授权
  因为storage自动创建pv需要经过kube-apiserver,所以要进行授权
  创建1个sa(serviceaccount)
  创建1个clusterrole，并赋予应该具有的权限，比如对于一些基本api资源的增删改查；
  创建1个clusterrolebinding，将sa和clusterrole绑定到一起；这样sa就有权限了；
  然后pod中再使用这个sa，那么pod再创建的时候，会用到sa，sa具有创建pv的权限，便可以自动创建pv；

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

注意：如果名称空间不是default，请自行修改

• 创建一个

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  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: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/nfs-subdir-external-provisioner:v4.0.2
          # resources:
          #    limits:
          #      cpu: 10m
          #    requests:
          #      cpu: 10m
          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.48.14
            - name: NFS_PATH
              value: /opt/data
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.48.14
            path: /opt/data

strategy:
type: Recreate Recreate：设置spec.strategy.type=Recreate，该策略下将杀掉正在运行的Pod，然后创建新的。
RollingUpdate：设置spec.strategy.type=RollingUpdate，滚动更新，即逐渐减少旧Pod的同时逐渐增加新Pod。
其中默认的RollingUpdate滚动更新策略的“边删除边更新”保证了在更新期间的服务可用性，在使用这个策略时，有两个可定义参数：
spec.strategy.RollingUpdate.maxUnavailable：更新过程中Pod数量可以低于Pod期望副本的数量或百分比（默认25%）
spec.strategy.RollingUpdate.maxSurge：更新过程中Pod数量可以超过Pod期望副本的数量或百分比（默认25%）

• 部署

#我这儿将上面的所有文件都放在了一个配置文件中，如果是分开的文件，请一个个创建
kubectl apply -f nfs.yaml 

查看

#查看storageclass
kubectl get sc
#查看sa
kubctl get sa
#查看deploy控制器
kubctl get deploy
#查看pod
kubctl get pod

3.4 测试

部署nginx服务，测试自动创建pv

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
   matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs-storage"
      resources:
        requests:
          storage: 1Gi

发布查看

kubectl get pvc,pv

我们可以看到，我们在没有创建pv的时候，只是创建了一个pvc，他就会配置要求自动创建一个符合要求的pv

进入共享目录，创建一个文件

删除web-0，检查文件是否存在

在有状态服务中，数据至关重要，通过测试，我们可以发现，虽然pod被删除重建，但是重建后的pod内的文件依然存在，保证了数据的安全性