k8s（五）卷：将磁盘挂载到容器
Kubernetes 的卷是 pod 的⼀个组成部分，并和 pod 共享相同的⽣命周期。
⼀、通过卷在容器之间共享数据
1.1. 使⽤ emptyDir 卷
创建⼀个 pod 中有两个共⽤同⼀个卷的容器：
# fortune-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: fortune
spec:
containers:
- image: luksa/fortune
name: html-generator
volumeMounts: # 名为 html 的卷挂载在容器的 /var/htdocs 中
- name: html
mountPath: /var/htdocs
- image: nginx:alpine
name: web-rver
volumeMounts: # 名为 html 的卷挂载在容器的 /usr/share/nginx/html 中，并且只读
- name: html
mountPath: /usr/share/nginx/html # Nginx 服务的默认服务⽂件⽬录
readOnly: true
ports:
- containerPort: 80
protocol: TCP
volumes:
- name: html # ⼀个名为 html 的单独 emptyDir 卷，挂载在上⾯的两个容器中
emptyDir: {}
luksa/fortune 每隔 10 秒钟随机写⼊⼀段⽂字到 /var/htdocs/index.html 中；nginx:alpine 是⼀个 Nginx 镜像。
kubectl create -f fortune-pod.yaml
使⽤端⼝转发查看 pod 状态：
kubectl port-forward fortune 8080:80
作为卷来使⽤的 emptyDir 是在承载 pod 的⼯作节点的实际磁盘上创建的，因此其性能取决于节点的磁盘类型。我们可以通知 Kubernetes 在 tmfs ⽂件系统（存在内存⽽⾮硬盘）上创建 emptyDir：
volumes:
- name: html
emptyDir:
medium: Memory
1.2. 使⽤ Git 仓库作为存储卷
gitRepo 卷本质上也是 emptyDir 卷，它通过克隆 Git 仓库并在 pod 启动时（但在创建容器之前）检出特定版本来填充数据。
apiVersion: v1
kind: Pod
metadata:
name: gitrepo-volume-pod
spec:
containers:
- image: nginx:alpine
name: web-rver
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
readOnly: true
ports:
- containerPort: 80
protocol: TCP
volumes:
- name: html
gitRepo:
repository: github/luksa/kubia-website-example.git
revision: master
directory: . # 将 repo 克隆到卷的根⽬录，如果不设置将会被克隆到 kubia-website-example ⽬录
⼆、访问⼯作节点⽂件系统上的⽂件
⼤多数 pod 应该忽略它们的主机节点，因此它们不应该访问节点⽂件系统上的任何⽂件。但是某些系统级别的 pod (切记，这些通常由DaemonSet 管理）确实需要读取节点的⽂件或使⽤节点⽂件系统来访问节点设备。Kubernetes 通过 hostPath 卷实现了这⼀点。hostPath 卷是我们介绍的第⼀种类型的持久性存储，因为gitRepo 和 emptyDir 卷的内容都会在 pod 被删除时被删除，⽽ hostPath 卷的内容则不
会被删除。如果你正在考虑使⽤ hostPath 卷作为存储数据库数据的⽬录，请重新考虑。因为卷的内容存储在特定节点的⽂件系统中，所以当数据库 pod 被重新安排在另⼀个节点时，会找不到数据。这解释了为什么对常规 pod 使⽤ hostPath 卷不是⼀个好主意，因为这会使pod 对预定规划的节点很敏感。
三、使⽤持久化存储
当运⾏在⼀个 pod 中的应⽤程序需要将数据保存到磁盘上，并且即使该 pod 重新调度到另⼀个节点时也要求具有相同的数据可⽤。这就不能使⽤到⽬前为⽌我们提到的任何卷类型，由于这些数据需要可以从任何集群节点访问，因此必须将其存储在某种类型的⽹络存储 (NAS)中。
如果使⽤ Google Kubernetes Engine 可以使⽤ GCE (Google Compute Engine) 卷；如果使⽤ AWS EC2 可以使⽤ awsElasticBlockStore 卷；如果使⽤ Azure 可以使⽤ azureFile 或者 azureDisk 卷。
四、从底层存储技术解耦 pod
到⽬前为⽌，我们探索过的所有待久卷类型都要求 pod 的开发⼈员了解集群中可⽤的真实⽹络存储的基础结构。例如，要创建⽀持 NFS 协议的卷，开发⼈员必须知道 NFS 节点所在的实际服务器。这违背了 Kubernetes 的基本理念，这个理念旨在向应⽤程序及其开发⼈员隐藏真实的基础设施，使他们不必担⼼基础设施的具体状
态，并使应⽤程序可在⼤量云服务商和数据企业之间进⾏功能迁移。
4.1. 持久卷、持久卷声明
在 Kubernetes 集群中为了使应⽤能够正常请求存储资源，同时避免处理基础设施细节，引⼊了两个新的资源，分别是持久卷（PersistentVolume 简称 PV）和持久卷声明（PersistentVolumeClaim 简称 PVC），这名字可能有点误导，因为正如在前⾯⼏节中看到的，甚⾄常规的 Kubernetes 卷也可以⽤来存储持久性数据。
当集群⽤户需要在其 pod 中使⽤持久化存储时，他们⾸先创建持久卷声明清单，指定所需要的最低容量要求和访问模式，然后⽤户将持久卷声明清单提交给 Kubernetes API 服务器，Kubernetes 将找到可匹配的持久卷并将其绑定到持久卷声明。
4.1.1. 创建持久卷
本⽂使⽤的依然是 Minikube:
kind: PersistentVolume
metadata:
name: mongodb-pv
spec:
capacity:
storage: 1Gi # 定义 PersistentVolume de ⼤⼩
accessModes: # 可以被单个客户端挂在为读写模式或者被多个客户端挂在为只读模式
- ReadWriteOnce
- ReadOnlyMany
persistentVolumeReclaimPolicy: Retain # 当声明被释放后，PersistentVolume 将会被保留（不清理和删除）
hostPath:
path: /tmp/mongodb
kubectl create -f mongodb-pv-hostpath.yaml
查看：
kubectl get pv
注意：持久卷不属于任何命名空间，它跟节点⼀样是集群层⾯的资源。
4.1.2. 创建持久卷声明
假设现在需要部署⼀个需要持久化存储的 pod，将要⽤到之前创建的持久卷，但是不能直接在 pod 内使⽤，需要先声明⼀个。声明⼀个持久卷和创建⼀个 pod 是相对独⽴的过程，因为即使 pod 被重新调度（重新调度意味着先前的 pod 被删除并且创建了⼀个新的 pod），我们也希望通过相同的持久卷声明来确保可⽤。
# mongodb-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mongodb-pvc # 声明的名称，稍后将声明当作 pod 的卷使⽤时需要⽤到
spec:
resources:
requests:
storage: 1Gi # 申请 1 GiB 的存储空间
accessModes:
- ReadWriteOnce # 允许单个客户端访问（同时⽀持读取和写⼊操作）
storageClassName: "" # 将空字符串指定为存储类名可确保 PVC 绑定到预先配置的 PV, ⽽不是动态配置新的 PV
kubectl create -f mongodb-pvc.yaml
查看：
kubectl get pvc
可以看到 PVC 已经与持久卷的 mongodb-pv 绑定。
访问模式：
RWO: ReadWriteOnce - 仅允许单个节点挂载读写
ROX: ReadOnlyMany - 允许多个节点挂载只读
RWX: ReadWriteMany - 允许多个节点挂载读写
访问模式涉及可以同时使⽤卷的⼯作节点的数量⽽⾮ pod 的数量。
持久卷是集群范围的，因此不能在特定的命名空间中创建，但是持久卷声明⼜只能在特定的命名空间创建，所以持久卷和持久卷声明只能被同⼀命名空间内的 pod 创建使⽤。
4.1.3. 在 pod 中使⽤持久卷声明
kind: Pod
metadata:
name: mongodb
spec:
containers:
- image: mongo
name: mongodb
volumeMounts:
- name: mongodb-data
mountPath: /data/db
ports:
- containerPort: 27017
protocol: TCP
volumes:
-
name: mongodb-data
persistentVolumeClaim:
claimName: mongodb-pvc # 在 pod 卷中通过名称引⽤持久卷声明
五、持久卷的动态卷配置
5.1. 通过 StorageClass 资源定义可⽤存储类型
# storageclass-fast-hostpath.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: k8s.io/minikube-hostpath # ⽤户配置持久卷的卷插件
parameters:
type: pd-ssd
kubectl create -f storageclass-fast-hostpath.yaml
5.2. 请求持久卷声明中的存储类
创建⼀个请求特定存储类的 PVC 定义
# mongodb-pvc-dp.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mongodb-pvc-fast
spec:
storageClassName: fast # 请求⾃定义存储类
resources:
requests:
storage: 100Mi
accessModes:
- ReadWriteOnce
kubectl create -f mongodb-pvc-dp.yaml
查看：
kubectl get pvc mongodb-pvc-fast
VOLUME 列显⽰了与此声明绑定的持久卷，执⾏命令，可以看到⾃动创建了⼀个新的 PV: kubectl get pv
5.3. 不指定存储类的动态配置
列出存储类：
kubectl get sc # sc 是 storageclass 的简写
查看默认存储类：
kubectl get sc standard -o yaml
创建⼀个没有指定存储类别的持久卷声明：
# mongodb-pvc-dp-nostorageclass.yaml apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mongodb-pvc2
spec:
resources:
requests:
storage: 100Mi
accessModes:
- ReadWriteOnce
kubectl create -f mongodb-pvc-dp-nostorageclass.yaml 查看：
kubectl get pvc mongodb-pvc2
