K8S PV 与 PVC

概念

PersistentVolume(PV)

是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。PV 是 Volume 之类的卷插件，但貝有独立于便用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统

PersistentVolumeClaim(PVC)

是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源(CPU和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或只读多次模式挂载）

静态pv

集群管理员创建一些PV。它们带有可供群集用户便用的实际存储的细节。它们存在 Kubernetes API中，可用于消费。

动态

当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，集群可能会尝试动态地为PVC 创建卷。此配置基于 StorageClasses：PVC 必须清求[存储类],并且管理员须创建并配置该类才能进行动态创建。声明该类为 "" 可以有效地禁用其动态配置。要启用基于存储级别的动态存储配置，集群理员需要启用 API server上的 DefaultStorageClass[准入控制器]。例如，通过确保 DefaultStorageClass 位于 API server 组件的 --admission-control 标志，使用逗号分隔的有序值列表中，可以完成此操作。

绑定

master 中的控制环路监视新的 PVC，寻找匹配的 PV (如果可能)，并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则该环路将始终将该 PV 绑定到 PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦 PV 和 PVC 绑定后，PersisitentVolumeClaim 绑定是排他性的，不管它们是如何绑定的。PVC 跟 PV 绑定是一对一的映射。

PV 访问模式

PersistentVolume 可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能，每个 PV 的访问模式都被设为该卷支持的特定模式。例如，NFS 可以支持多个读/写客户端，但特定的 NFS PV 可能以只方式导出到服务器上。每个PV都有一套自己的用来描述特定功能的访问模式

• ReadWriteOnce -- 该卷可以被单个节点以读/写模式佳载
• ReadOnlyMany -- 该卷可以被多个节点以只读模式挂载
• ReadWriteMany -- 该卷可以被多个节点以读／写模式挂载

在命令行中，访问模式缩写为：

• RWO-ReadWriteOnce
• ROX-ReadOnlyMany
• RWX．ReadWriteMany
  

回收策略

• Retain（保留）-- 手动回收
• Recycle（回收）-- 基本擦除（rm -rf /thevolume/*）
• Delete（删除）-- 关朕的存储资产（例如 AWS EBS, GCE PD, Azure Disk OpenStack Cinder卷) 被删除
  当前，只有 NFS 和 HostPath 支持回收策路。AWS EBS，GCE PD，Azure Disk 和 Cinder 卷支持删策

状态

卷可以处于以下的某种状态：

• Available（可用）-- 块空闲资源还没有被任何声明绑定
• Bound（已绑定）-- 卷已经被声明绑定
• Released（已释放）-- 声明被删除，但是资源还未被集群重新声明
• Failed (失败) -- 该卷的自动回收失败
  命令行会显示绑定到 PV 的 PVC 的名称。

持久化演示说明 - NFS

安装 NFS 服务器

在 k8s-node2 上安装

yum install nfs-common nfs-utils rpcbind -y
mkdir /{nfs,nfs2}
chown nfsnobody /nfs
chown nfsnobody /nfs2
chmod 777 nfs2/
chmod 777 /nfs

vi /etc/exports
/nfs *(rw,no_root_squash,no_all_squash,sync)
/nfs2 *(rw,no_root_squash,no_all_squash,sync)

systemctl start rpcbind
systemctl start nfs

cd /nfs
echo "klvchen" > index.html

# NFS Squash：设置来访的普通用户及 root 账户权限。其中：
# All_Squash：所有访问用户都会被映射为匿名用户或用户组；
# No_All_Squash：访问用户会先与本机用户匹配，匹配失败后再映射为匿名用户或用户组；
# Root_Squash：将来访的 root 用户映射为匿名用户或用户组；
# No_Root_Squash：来访的 root 用户保持 root 帐号权限；

# sync	同时将数据写入到内存与硬盘中，保证不丢失数据
# async	优先将数据保存到内存，然后再写入硬盘；这样效率更高，但可能会丢失数据

部署 pv

mkdir ~/PV
cd ~/PV

vi pv.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv1
spec:
  capacity:
    storage: 8Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  nfs:
    path: /nfs
    server: 192.168.31.207
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfspv2
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  nfs:
    path: /nfs2
    server: 192.168.31.207

kubectl apply -f pv.yaml 

创建服务并使用 PVC

vi pvc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: wangyanglinux/myapp:v1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteMany" ]
      storageClassName: "nfs"
      resources:
        requests:
          storage: 1Gi

kubectl apply -f pvc.yaml 

kubectl get pods -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
web-0   1/1     Running   0          29m   10.244.1.44   k8s-node01   <none>           <none>
web-1   1/1     Running   0          27m   10.244.2.29   k8s-node02   <none>           <none>

curl 10.244.1.44
klvchen