以下將說明關於Local volume 與hostPath二種類型的差異與一些注意事項。
1. HostPath
hostPath是將節點內的檔案、目錄映射進Pod內，支援類型：File, Directory, Socket, BlockDevice。
apiVersion: v1使用上要注意：
kind: Pod
metadata:
name: test-pod2
spec:
containers:
- image: busybox
name: test-hostpath
command: [ "sleep", "3600" ]
volumeMounts:
- mountPath: /test-data
name: test-volume
volumes:
- name: test-volume
hostPath:
# directory location on host
path: /data
# this field is optional
type: Directory
- 要使用hostpath volume建議搭配NodeSelector來做配置，但數量一多就很煩人。
- 如果套用
DirectoryOrCreate或FileOrCreate，要確定kubelet有在節點上Create file/directory的權限。 - 如果節點上的File/Directory是由
root建立的，在掛到容器後，還要確認容器有沒有權限進行讀寫 - Kubernetes scheduler不會考慮
hostPath volume的大小，也無法設定大小，所以必須用其他方式進行檢查。
2. Local volume
Local volume的機制是掛載本地的儲存資源，像是Disk, partition, folder。讓這些資源可以被kubernetes以static pv的方式取得。
主要就是要用來解決HostPath的問題。會由PV controller與Scheduler做local pv做邏輯上的額外處理，才能實現在Pod re-schedule時，可以再排程到local volume所在的節點。
Local volume可以確保Pod與PV一定可以被scheduled到相同的worker node上。
3. 使用Local volume的時機
- 需要從遠端的storage預先載入到本地的目錄，用來加速Pod讀取資料的速度(Cache)，這種情況為ReadOnly，所以不怕資料損壞，現在有些AI在訓練時也會採用這種方式。
- 本地有建立SDS解決方案，因為本身就有replicas，所以也可以採用local pv。
- 不適合在需要做scaling的環境使用
4. 使用Local volume注意事項
- 在寫PV時，可以
.spec.nodeAffinityfield部份來說明local volume與node的綁定關係 - 如果使用
local-storage storageclass時，可以使用volumeBindingMode: WaitForFirstConsumer來實現延遲定，讓PV controller不會立刻為PVC做Bound，等到需要使用這個local pv的Pod完成排程後，再去做Bound。
為了改善這些問題，官方再提出一個local volume provisionner的解決方案來處理這些問題
(1) 監控配置好的掛載點，建立對應storageClassName, path, nodeAffinity, capacity的PV
(2) 刪除PVC後，自動清理local mount的所有內容，並刪除對應的PV
(3) 只有一開始的local volume的掛載需要人工，其他都由provisionner處理。
Reference:
