Local volume vs HostPath

以下將說明關於Local volume 與hostPath二種類型的差異與一些注意事項。

1. HostPath

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

使用上要注意：

1. 要使用hostpath volume建議搭配NodeSelector來做配置，但數量一多就很煩人。
2. 如果套用DirectoryOrCreate或FileOrCreate，要確定kubelet有在節點上Create file/directory的權限。
3. 如果節點上的File/Directory是由root建立的，在掛到容器後，還要確認容器有沒有權限進行讀寫
4. 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:

• Kubernetes local static provisioner
• Kubernetes hostpath和local volume区别