Kubernetes 实战 pv and pvc

前文介绍了 Kubernetes volume，
对于云计算运维、维护人员来说是相当麻烦的，如果有100个用户申请volume 就得人工操作100次，有虚拟化经验的人应该比较清楚共享存储的操作概念，相当于在公有云或者私有云的环境中内置多个存储服务器，当用户申请虚拟机磁盘时直接向控制中心提交申请（磁盘空间大小、磁盘模式预分配或者 精简置备、磁盘类型如isisc、fc、nfs等等），控制中心会根据用户提交的配置信息自动去存储服务器匹配、划分，这样就大大增加了自动化，好了下面介绍Kubernetes如何解决这些问题。

介绍

对于管理计算资源来说，管理存储资源明显是另一个问题。PersistentVolume 子系统为用户和管理员提供了一个 API，该 API 将如何提供存储的细节抽象了出来。为此，我们引入两个新的 API 资源：PersistentVolume 和 PersistentVolumeClaim。

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

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

pvc 选择流程

用户创建或已经创建了具有特定存储量的 PersistentVolumeClaim 以及某些访问模式。master 中的控制环路监视新的 PVC，寻找匹配的 PV（如果可能），并将它们绑定在一起。如果为新的 PVC 动态调配 PV，则该环路将始终将该 PV 绑定到 PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求的数量。一旦 PV 和 PVC 绑定后，PersistentVolumeClaim 绑定是排他性的，不管它们是如何绑定的。 PVC 跟 PV 绑定是一对一的映射。

如果没有匹配的卷，声明将无限期地保持未绑定状态。随着匹配卷的可用，声明将被绑定。例如，配置了许多 50Gi PV的集群将不会匹配请求 100Gi 的PVC。将100Gi PV 添加到群集时，可以绑定 PVC。

定义pv

pv.yml 链接
这里采用nfs 演示，nfs搭建可以查看： Ubuntu 16 NFS的安装与使用

apiVersion: v1
kind: PersistentVolume
metadata:
  name: restapi-pv
spec:
  accessModes:
  - ReadWriteMany
  volumeMode: Filesystem
  storageClassName: slow
  capacity:
    storage: 20Gi
  persistentVolumeReclaimPolicy: Recycle
  nfs:
    path: /data/k8svolume
    server: 114.115.180.117

不熟悉k8s的可以通过rancher 操作，界面化操作非常简单；

创建

kubectl apply -f pv.yml

查看

kubectl get pv

NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                 STORAGECLASS   REASON    AGE
restapi-pv   20Gi       RWX            Recycle          Bound     default/restapi-pvc   slow                     1h

定义 pvc

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

存储模式包括：

ReadWriteOnce——该卷可以被单个节点以读/写模式挂载
ReadOnlyMany——该卷可以被多个节点以只读模式挂载
ReadWriteMany——该卷可以被多个节点以读/写模式挂载 在命令行中

访问模式缩写为：

RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany

重要！一个卷一次只能使用一种访问模式挂载，即使它支持很多访问模式。例如，GCEPersistentDisk 可以由单个节点作为
ReadWriteOnce 模式挂载，或由多个节点以 ReadOnlyMany 模式挂载，但不能同时挂载。

感兴趣的可以关注k8s原文
pvc.yml 链接

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restapi-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  volumeMode: Filesystem
  storageClassName: slow

创建

kubectl apply -f pvc.yml

查看

kubectl get pvc

NAME          STATUS    VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
restapi-pvc   Bound     restapi-pv   20Gi       RWX            slow           1h

定义 deployment 绑定 pvc

deployment-pvc.yml 链接

apiVersion: apps/v1
kind: Deployment
metadata:
  name: restapi
spec:
  replicas: 1
  selector:
    matchLabels:
      app: restapi
  template:
    metadata:
      labels:
        app: restapi
        tier: backend
        track: stable
    spec:
      containers:
      - name: restapi
        image: xiliangma/restapi:latest
        imagePullPolicy: IfNotPresent
        ports:
        - name: dev
          containerPort: 8080
        - name: prod
          containerPort: 8088
        - name: https
          containerPort: 443
        resources:
          limits:
            cpu: 1000m
            memory: 1024Mi
          requests:
            cpu: 300m
            memory: 256Mi
        livenessProbe:
          httpGet:
            path: /swagger
            port: 8080
            scheme: HTTP 
          initialDelaySeconds: 60
          periodSeconds: 30
          timeoutSeconds: 3
          failureThreshold: 3
        volumeMounts:
        - mountPath: /tmp/cache
          name: test-volume # 通过指定名称关联存储
      volumes:
      - name: test-volume
        persistentVolumeClaim:
          claimName: restapi-pvc

创建

kubectl apply -f deployment-pvc.yml

查看

kubectl get deployment

NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
restapi   1         1         1            1           1h