查看持久卷申请
vagrant@ubuntu-xenial:~/dockerimages/kubernetes/mysql$ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE mysql-pv-claim Bound pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa 1Gi RWO standard 10m查看持久卷申请详细信息
vagrant@ubuntu-xenial:/mnt$ kubectl describe pvc mysql-pv-claim Name: mysql-pv-claim Namespace: default StorageClass: standard Status: Bound Volume: pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa Labels: app=mysql ...显示持久卷：
vagrant@ubuntu-xenial:/mnt$ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa 1Gi RWO Delete Bound default/mysql-pv-claim standard 24h键入“kubectl describe pv pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa”， 显示持久卷详细信息。从这里可以看出，虚拟机上的持久卷在如下位置：“Path： /tmp/hostpath-provisioner/pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa”。
vagrant@ubuntu-xenial:/mnt$ kubectl describe pv pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa Name: pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa Labels: <none> Annotations: hostPathProvisionerIdentity: 19948fdf-e67f-11e9-8fbd-026a5b40726f pv.kubernetes.io/provisioned-by: k8s.io/minikube-hostpath Finalizers: [kubernetes.io/pv-protection] StorageClass: standard Status: Bound Claim: default/mysql-pv-claim Reclaim Policy: Delete Access Modes: RWO VolumeMode: Filesystem Capacity: 1Gi Node Affinity: <none> Message: Source: Type: HostPath (bare host directory volume) Path: /tmp/hostpath-provisioner/pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa HostPathType: Events: <none>查看MySQL目录信息：
vagrant@ubuntu-xenial:/tmp/hostpath-provisioner/pvc-ac6c88d5-ef5a-4a5c-b499-59715a2d60fa$ ls -al total 188488 drwxrwxrwx 6 999 docker 4096 Oct 4 13:23 . drwxr-xr-x 3 root root 4096 Oct 4 12:58 .. -rw-r----- 1 999 docker 56 Oct 4 12:58 auto.cnf -rw------- 1 999 docker 1679 Oct 4 12:59 ca-key.pem -rw-r--r-- 1 999 docker 1107 Oct 4 12:59 ca.pem -rw-r--r-- 1 999 docker 1107 Oct 4 12:59 client-cert.pem -rw------- 1 999 docker 1679 Oct 4 12:59 client-key.pem -rw-r----- 1 999 docker 668 Oct 4 13:21 ib_buffer_pool -rw-r----- 1 999 docker 79691776 Oct 4 13:23 ibdata1 -rw-r----- 1 999 docker 50331648 Oct 4 13:23 ib_logfile0 -rw-r----- 1 999 docker 50331648 Oct 4 12:58 ib_logfile1 -rw-r----- 1 999 docker 12582912 Oct 4 13:24 ibtmp1 drwxr-x--- 2 999 docker 4096 Oct 4 12:58 mysql drwxr-x--- 2 999 docker 4096 Oct 4 12:58 performance_schema -rw------- 1 999 docker 1679 Oct 4 12:59 private_key.pem -rw-r--r-- 1 999 docker 451 Oct 4 12:59 public_key.pem -rw-r--r-- 1 999 docker 1107 Oct 4 12:59 server-cert.pem -rw------- 1 999 docker 1675 Oct 4 12:59 server-key.pem drwxr-x--- 2 999 docker 4096 Oct 4 13:18 service_config drwxr-x--- 2 999 docker 12288 Oct 4 12:58 sys 持久卷的回收模式：当持久卷和持久卷申请被删除后，它有三种回收模式。
保持（Retain）：当持久卷申请被删除后，持久卷仍在。你可以手动回收持久卷里的数据。
** 删除（Delete）**：持久卷申请和持久卷都被删除，底层存储的数据也会被删除。当使用动态持久卷时，缺省的模式是Delete。当然，你可以在持久卷被创建之后修改它的回收模式。
** 回收（Recycle）**：这种方式已经不推荐使用了，建议用Retain代替。
静态持久卷：动态持久卷的一个问题是它的缺省回收模式是“删除”，这样当虚机重新启动后，持久卷会被删除。当你重新运行部署时，k8s会创建一个新的MySQL，这样原来MySQL里的新建信息就会丢失，这是我们不愿意看到的。虽然你可以手动修改回收方式为“保持”，但还是要手动回收原来持久卷里的数据。
一个解决办法是把持久卷建在宿主机上，这样即使虚机出了问题被重新启动，MySQL里的新建信息依然不会丢失。如果是在云上，就会有专门的的存储层，如果是本地，大致有三种方式：
Local：把存储从宿主机挂载到k8s集群上. 详情请参见："".
HostPath：也是把存储从宿主机挂载到k8s集群上，但它有许多限制，例如只支持单节点（Node），而且只支持“ReadWriteOnce”模式。详情请参见： "hostPath as volume in kubernetes".
NFS：网络文件系统，这种是最灵活的，但需要安装NFS服务器。详情请参见："Kubernetes Volumes Guide".
我选择了比较简单的“Local”方式。在这种方式下，必须单独创建持久卷，不能 只创建持久卷申请而让系统自动创建持久卷。
下面是使用“Local”方式的配置文件，它把持久卷和持久卷申请写在了一个文件里。当用“Local”方式时，需要设置“nodeAffinity”部分，其中“values:- minikube” 的“Minikube”是k8s集群Node的名字，“Minikube”只支持一个Node，既是“Master Node”，又是“Worker Node”。