kubernetes(k8s) 學習 (十) k8s存儲之 Volumes (簡介+emptyDir卷+hostpath卷+nfs卷)

Volumes簡介

容器中的文件在磁盤上是臨時存放的,這給容器中運行的特殊應用程序帶來一些問題。
首先,當容器崩潰時,kubelet 將重新啓動容器,容器中的文件將會丟失,因爲容器會以乾淨的狀態重建。
其次,當在一個 Pod 中同時運行多個容器時,常常需要在這些容器之間共享文件。 Kubernetes 抽象出 Volume 對象來解決這兩個問題。

Kubernetes 卷具有明確的生命週期,與包裹它的 Pod 相同。 因此,卷比 Pod 中運行的任何容器的存活期都長,在容器重新啓動時數據也會得到保留。 當然,當一個 Pod 不再存在時,卷也將不再存在。也許更重要的是,Kubernetes 可以支持許多類型的卷,Pod 也能同時使用任意數量的卷

卷不能掛載到其他卷,也不能與其他卷有硬鏈接。 Pod 中的每個容器必須獨立地指定每個卷的掛載位置

在這裏插入圖片描述

Kubernetes 的卷的類型

awsElasticBlockStore 、azureDisk、azureFile、cephfs、cinder、configMap、csi downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flocker
gcePersistentDisk、gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、nfs、persistentVolumeClaim、projected、portworxVolume、quobyte、rbd scaleIO、secret、storageos、vsphereVolume

emptyDir卷

當 Pod 指定到某個節點上時,首先創建的是一個 emptyDir 卷,並且只要 Pod 在該節點上運行,卷就一直存在
就像它的名稱表示的那樣,卷最初是空的。 儘管 Pod 中的容器掛載 emptyDir 卷的路徑可能相同也可能不同,但是這些容器都可以讀寫 emptyDir 卷中相同的文件。 當 Pod 因爲某些原因被從節點上刪除時,emptyDir 卷中的數據也會永久刪除

emptyDir 的使用場景:

緩存空間,例如基於磁盤的歸併排序。
爲耗時較長的計算任務提供檢查點,以便任務能方便地從崩潰前狀態恢復執行。
在 Web 服務器容器服務數據時,保存內容管理器容器獲取的文件。

默認情況下, emptyDir 卷存儲在支持該節點所使用的介質上;這里的介質可以是磁盤或 SSD 或網絡存儲,這取決於您的環境

但是,您可以將 emptyDir.medium 字段設置爲 “Memory”,以告訴 Kubernetes 爲您安裝 tmpfs(基於內存的文件系統)

雖然 tmpfs 速度非常快,但是要注意它與磁盤不同。 tmpfs 在節點重啓時會被清除,並且您所寫入的所有文件都會計入容器的內存消耗,受容器內存限制約束

emptyDir 示例

apiVersion: v1
kind: Pod
metadata:
  name: vol1
spec:
  containers:
  - image: busyboxplus
    name: vm1
    command: ["sleep", "300"]
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  - name: vm2
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir:
      medium: Memory
      sizeLimit: 100Mi
$ kubectl  exec vol1 -it sh
/ # dd if=/dev/zero of=/cache/bigfile bs=1M count=200
200+0 records in
200+0 records out

$ kubectl  get pod -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP       NODE        
vol1      0/1        Evicted            0          98s   <none>   server2 

可以看到文件超過sizeLimit,則一段時間後(1-2分鐘)會被kubelet evict掉。之所以不是“立即”被evict,是因爲kubelet是定期進行檢查的,這裏會有一個時間差。

emptydir缺點:
不能及時禁止用戶使用內存。雖然過1-2分鐘kubelet會將Pod擠出,但是這個時間內,其實對node還是有風險的;

影響kubernetes調度,因爲empty dir並不涉及node的resources,這樣會造成Pod“偷偷”使用了node的內存,但是調度器並不知曉;

用戶不能及時感知到內存不可用

1.在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
2.在這裏插入圖片描述在這裏插入圖片描述

在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
測試emptydir的缺點
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述

hostPath 卷

它能將主機節點文件系統上的文件或目錄掛載到您的 Pod 中。 雖然這不是大多數 Pod 需要的,但是它爲一些應用程序提供了強大的逃生艙。

hostPath 的一些用法有:
運行一個需要訪問 Docker 引擎內部機制的容器,掛載 /var/lib/docker 路徑。

在容器中運行 cAdvisor 時,以 hostPath 方式掛載 /sys。

允許 Pod 指定給定的 hostPath 在運行 Pod 之前是否應該存在,是否應該創建以及應該以什麼方式存在。

除了必需的 path 屬性之外,用戶可以選擇性地爲 hostPath 卷指定 type
在這裏插入圖片描述
當使用這種類型的卷時要小心,因爲:
具有相同配置(例如從 podTemplate 創建)的多個 Pod 會由於節點上文件的不同而在不同節點上有不同的行爲。

當 Kubernetes 按照計劃添加資源感知的調度時,這類調度機制將無法考慮由 hostPath 使用的資源。

基礎主機上創建的文件或目錄只能由 root 用戶寫入。您需要在 特權容器 中以 root 身份運行進程,或者修改主機上的文件權限以便容器能夠寫入 hostPath 卷。

hostPath 示例

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /data
      type: DirectoryOrCreate

查看pod調度節點是否創建相關目錄

1.在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
2.在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述在這裏插入圖片描述

nfs卷

在這裏插入圖片描述

NFS 示例
apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: nginx
    name: test-container
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: test-volume
  volumes:
  - name: test-volume
    nfs:
      server: 172.25.0.17
      path: /nfsdata

1.首先在ser1上搭建好nfs,使它成爲nfs服務器。這裏不再贅述
在這裏插入圖片描述

在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
2.在ser3上查看
在這裏插入圖片描述
在這裏插入圖片描述
3.測試在容器中寫入數據時
在這裏插入圖片描述在這裏插入圖片描述
在這裏插入圖片描述

在nfs服務器上查看
在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章