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
