本文是《深入剖析k8s》学习笔记的第四篇，主要对k8s中的存储数据卷进行分析和学习。
容器中的存储是不稳定的，一旦容器重启或者销毁，这些存储就都会丢失。所以真实使用场景下，都会以数据卷挂载的方式将外部存储应用到容器中，带来的好处就是：
- 数据卷存储内容独立于容器的生命周期，不会受容器的重建或者销毁而丢失；
- 容器之间、容器和宿主机之间的数据共享变得简单方便；
在k8s中，如果要在容器中使用数据卷，需要像如下一个pod的yaml示例一样进行声明定义：
apiVersion: V1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- image: gcr.io/google_containers/test-webserver
name: test
# 定义容器使用的数据卷及挂载路径
volumeMounts:
# 挂载到容器中的/volume路径
- mountPath: /volume
# 使用my-volume这个数据卷
name: my-volume
volumes:
- name: my-volume
emptyDir: {}
其中pod的定义中，声明使用了自定义名称为my-volume的数据卷，并且类型为emptyDir；k8s的volume支持多种数据类型，可以通过命令kubectl explain pod.spec.volumes来查看所有支持的volume类型，其中常用的类型及意义比较如下：
- emptyDir，在pod当前所在节点上新建一个匿名的临时空目录，生命周期同pod，只要pod还在，该存储卷就是安全的；
- hostPath，将pod当前所在节点上的某个已存在文件目录作为数据卷使用，即使pod被删除，存储也是安全的；但是不能被迁移到别的节点上；
- persistentVolumeClaim，使用PVC存储卷，是目前主流的使用方式，这个在下面详细说明；好处就是永久保存，pod即使被调度到别的节点，也不影响读写；
从工程分工角度上来说，存储的定义和声明应该由运维人员完成，开发人员只要使用即可。因此，为了避免将存储细节过度地暴露给开发人员，k8s才引进了Persistent Volume Claim(PVC)和Persistent Volume(PV)这两个API对象，同时也降低了开发人员使用存储卷的门槛。如此，开发人员只需要如下两步就能解决存储卷的使用问题：
-
定义PVC；表示开发人员对存储的声明；
kind: PersistentVolumeClaim apiVersion: V1 metadata: name: my-pvc spec: accessModes: # 可读写，但是只能被挂载在一个节点上，不支持多节点挂载共享 - ReadWriteOnce # pv需要手动创建后才会被k8s自动绑定pvc，对应pv的该属性值必须和此处一致 storageClassName: manual resources: requests: # 需要存储大小为1GB storage: 1Gi -
使用PVC；
apiVersion: V1 kind: Pod metadata: name: test-pod spec: containers: - image: gcr.io/google_containers/test-webserver name: test # 定义容器使用的数据卷及挂载路径 volumeMounts: # 挂载到容器中的/volume路径 - mountPath: /volume # 使用my-volume这个数据卷 name: my-volume volumes: - name: my-volume # volume类型使用PVC persistentVolumeClaim: # 使用第一步中定义的PVC名称 claimName: my-pvc
那么开发人员声明的PVC到底使用的是什么存储卷呢，这个就由运维人员负责维护就行了，如下是一个PV的定义，开发人员了解即可：
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv
spec:
# pv需要手动创建后才会被k8s自动绑定pvc，对应pvc的该属性值必须和此处一致
storageClassName: manual
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
# 该PV使用nfs来实现
nfs:
server: 10.244.1.4
path: "/"
为什么这个PV可以和上面的PVC绑定呢？只要符合如下的条件，k8s就会自动将它们绑定，绑定后，在PVC的配置文件中就能看到使用的数据卷就是该PV了。
- 存储大小匹配，pv要能满足pvc的要求；
- storageClassName值必须一致；
总的来说，PVC和PV的关系就像是接口和实现的关系，PVC是接口定义，声明要使用什么，至于怎么实现，就是PV去完成的事情。如此解耦，使得开发和运维都能高效地搞定存储。
假设开发人员在创建好带有PVC的pod之后，且pod已经运行了，才发现运维还没有来得及创建对应的PVC或者PVC创建有问题，致使pod存储卷使用有问题该怎么办？只要运维及时创建对应的PV，k8s中的volume controller会循环遍历没有成功绑定PV的PVC，帮它们寻找合适的PV进行绑定。
一个k8s集群往往有很多开发团队在使用，开发会部署很多pod，如果这些pod都需要存储卷，运维人员就需要天天创建pv来满足开发人员pvc绑定的需求了，太浪费人力，所以这种重复工作就被k8s中的storageClass取代了。原先手动创建PV的方式被称为static provisioning，使用storageClass自动创建PV的方式被称为dynamic provisioning，storageClass其实就是PV的一个模板，其定义大致分为两个部分：
- PV的属性定义，比如存储类型、大小等；
- PV的底层存储实现，比如使用哪种存储插件；
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: my-storageclass
# 使用的存储插件
provisioner: kubernetes.io/gce-pd
# 关于PV属性的定义
parameters:
type: pd-ssd
在开发人员创建PVC的时候，只要指定使用的storageClassName是如上定义和创建的my-storageclass，那么k8s就会根据该storageClass自动创建一个PV与该PVC绑定。
