Kubernetes持久卷怎么使用

146次閱讀

沒有評論

共計 8489 個字符，預計需要花費 22 分鐘才能閱讀完成。

本篇內容主要講解“Kubernetes 持久卷怎么使用”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“Kubernetes 持久卷怎么使用”吧!

Volume 卷

Container 中的文件在磁盤上是臨時存放的，這給 Container 中運行的較重要的應用程序帶來一些問題：

1. 當容器崩潰時，kubelet 會重新啟動容器，但容器會以干凈的狀態重啟，造成文件的丟失。

2.Pod 中運行多個容器時，希望能在多個容器中共享文件。

因此 Kubernetes 使用了卷（Volume）這一抽象概念能夠來解決這兩個問題。Kubernetes 支持下列類型的卷：

hostpath：將主機節點文件系統上的文件或目錄掛載到你的 Pod 中。

emptyDir: 當 Pod 分派到某個 Node 上時，emptyDir 卷會被創建，并且在 Pod 在該節點上運行期間，卷一直存在。就像其名稱表示的那樣，卷最初是空的。Pod 中的多個容器可以共享 emptyDir 卷中的文件。當 Pod 因為某些原因被從節點上刪除時，emptyDir 卷中的數據也會被永久刪除。容器崩潰并不會導致 Pod 被從節點上移除，因此容器崩潰期間 emptyDir 卷中的數據是安全的。

Persistent Volume：persistentVolumeClaim 卷用來將持久卷（PersistentVolume）掛載到 Pod 中。持久卷申領（PersistentVolumeClaim）是用戶在不知道特定云環境細節的情況下申領持久存儲（例如 NFS，iSCSI）的一種方法。

Persistent Volume 持久卷

本文主要介紹持久卷的使用。Kubernetes 為了使開發人員能夠在請求存儲資源時，避免處理存儲設施細節，引入了持久卷（PersistentVolume，PV）和持久卷申領（PersistentVolumeClaim，PVC）：

持久卷（PersistentVolume，PV 是集群中的一塊存儲，可以由管理員事先供應，或者使用存儲類（Storage Class）來動態供應。持久卷是集群資源，就像節點也是集群資源一樣。PV 持久卷和普通的 Volume 一樣，也是使用卷插件來實現的，只是它們擁有獨立于任何使用 PV 的 Pod 的生命周期。此 API 對象中記述了存儲的實現細節，無論其背后是 NFS、iSCSI 還是特定于云平臺的存儲系統。

持久卷申領（PersistentVolumeClaim，PVC 表達的是用戶對存儲的請求。概念上與 Pod 類似。Pod 會耗用節點資源，而 PVC 申領會耗用 PV 資源。Pod 可以請求特定數量的資源（CPU 和內存）；同樣 PVC 申領也可以請求特定的大小和訪問模式（例如，可以要求 PV 卷能夠以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一來掛載）。

創建 PV 有兩種方式：

靜態供應：一種是集群管理員通過手動方式靜態創建應用所需要的 PV。

動態供應：

方式一：用戶手動創建 PVC 并由 Provisioner 組件動態創建對應的 PV。

方式二：在創建 Pod 的時候使用 volumeClaimTemplates 聲明。

PV 回收策略

保留（Retain）保留策略允許手動回收資源，當刪除 PVC 的時候，PV 仍然存在，變為 Realease 狀態，需要用戶手動通過以下步驟回收卷（只有 hostPath 和 nfs 支持 Retain 回收策略）：

1. 刪除 PV。

2. 手動清理存儲的數據資源。

回收（Resycle）該策略已廢棄，推薦使用 dynamic provisioning，回收策略會在 volume 上執行基本擦除（rm -rf /thevolume/*），可被再次聲明使用。

刪除（Delete）

當發生刪除操作的時候，會從 Kubernetes 集群中刪除 PV 對象，并執行外部存儲資源的刪除操作（根據不同的 provisioner 定義的刪除邏輯不同，有的是重命名而不是刪除）。

動態配置的卷繼承其 StorageClass 的回收策略，默認為 Delete，即當用戶刪除 PVC 的時候，會自動執行 PV 的刪除策略。

訪問模式

訪問模式有：

ReadWriteOnce — 卷可以被一個節點以讀寫方式掛載；

ReadOnlyMany — 卷可以被多個節點以只讀方式掛載；

ReadWriteMany — 卷可以被多個節點以讀寫方式掛載。

在命令行接口（CLI）中，訪問模式也使用以下縮寫形式：

RWO — ReadWriteOnce

ROX — ReadOnlyMany

RWX — ReadWriteMany

每個卷只能同一時刻只能以一種訪問模式掛載，即使該卷能夠支持多種訪問模式。例如，一個 GCEPersistentDisk 卷可以被某節點以 ReadWriteOnce 模式掛載，或者被多個節點以 ReadOnlyMany 模式掛載，但不可以同時以兩種模式掛載。

卷綁定模式

volumeBindingMode 字段控制了 PVC 和 PV 在什么時候進行綁定。

Immediate：表示一旦創建了 PVC 也就完成了卷綁定和動態制備。對于由于拓撲限制而非集群所有節點可達的存儲后端，PV 會在不知道 Pod 調度要求的情況下綁定或者制備。

WaitForFirstConsumer：該模式將延遲 PV 的綁定和制備，直到使用該 PVC 的 Pod 被創建。PV 會根據 Pod 調度約束指定的拓撲來選擇或制備，包括但不限于資源需求、節點篩選器、pod 親和性和互斥性、以及污點和容忍度。

靜態供應

靜態供應需要管理員手動創建 PV，然后創建 PVC 綁定 PV，最后創建 Pod 聲明使用 PVC。

創建 PV

apiVersion: v1
kind: PersistentVolume
metadata:
 name: task-pv-volume
 labels:
 type: local
spec:
 storageClassName: manual # 靜態供應，名字可以任意取
 capacity:
 storage: 10Gi
 accessModes:
 - ReadWriteOnce
 hostPath:
 path:  /mnt/data  # 在創建 pod 的節點上會新建該目錄

創建 PVC

fapiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: task-pv-claim
spec:
 storageClassName: manual #storageClassName 要和 PV 中的一致
 accessModes:
 - ReadWriteOnce #accessMode 要和 PV 中的一致
 resources:
 requests:
 storage: 3Gi # 申請 3G 容量，申請就近原則，如果有一個 10G 的和一個 20G 的 PV 滿足要求，那么使用 10G 的 PV

創建 Pod 掛載 PV

apiVersion: v1
kind: Pod
metadata:
 name: task-pv-pod
spec:
 volumes:
 - name: task-pv-storage
 persistentVolumeClaim:
 claimName: task-pv-claim # 使用的 PVC 的名字
 containers:
 - name: task-pv-container
 image: nginx
 ports:
 - containerPort: 80
 name:  http-server 
 volumeMounts:
 - mountPath:  /usr/share/nginx/html  # 容器中掛載的目錄
 name: task-pv-storage

在宿主機上的目錄創建一個文件：

root@worker01:~# cd /mnt/data/
root@worker01:/mnt/data# echo  volume nginx    index.html

嘗試訪問 Pod 的服務，可以看到 nginx 的 index.html 文件已經被修改：

root@master01:~/yaml/volume# kubectl get pod -o wide 
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
task-pv-pod 1/1 Running 0 11m 192.168.5.17 worker01  none   none 
root@master01:~/yaml/volume# curl 192.168.5.17
volume nginx

刪除要按照 Pod– PVC– PV 的順序刪除，如果先刪除了 PVC 會等 Pod 刪除掉，才會刪除 PVC，如果先刪除了 PV，會等 pod 和 PVC 刪除了才會刪除 PV。

動態供應

動態卷供應允許按需創建存儲卷。如果沒有動態供應，集群管理員必須手動地聯系他們的云或存儲提供商來創建新的存儲卷，然后在 Kubernetes 集群創建 PersistentVolume 對象來表示這些卷。動態供應功能消除了集群管理員預先配置存儲的需要。相反，它在用戶請求時自動供應存儲。

安裝 NFS 安裝 NFS 服務端

root@master01:/# apt-get -y install nfs-kernel-server 
root@master01:/# systemctl enable nfs-kernel-server.service   systemctl restart nfs-kernel-server.service

安裝 NFS 客戶端

在 worker 節點安裝 NFS 客戶端：

root@worker01:~# apt-get -y install nfs-common

配置存儲插件配置 RBAC

apiVersion: v1
kind: ServiceAccount
metadata:
 name: nfs-client-provisioner
 # replace with namespace where provisioner is deployed
 namespace: default
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: nfs-client-provisioner-runner
rules:
 - apiGroups: [ ]
 resources: [persistentvolumes]
 verbs: [get ,  list ,  watch ,  create ,  delete]
 - apiGroups: [ ]
 resources: [persistentvolumeclaims]
 verbs: [get ,  list ,  watch ,  update]
 - apiGroups: [storage.k8s.io]
 resources: [storageclasses]
 verbs: [get ,  list ,  watch]
 - apiGroups: [ ]
 resources: [events]
 verbs: [create ,  update ,  patch]
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: run-nfs-client-provisioner
subjects:
 - kind: ServiceAccount
 name: nfs-client-provisioner
 # replace with namespace where provisioner is deployed
 namespace: default
roleRef:
 kind: ClusterRole
 name: nfs-client-provisioner-runner
 apiGroup: rbac.authorization.k8s.io
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: leader-locking-nfs-client-provisioner
 # replace with namespace where provisioner is deployed
 namespace: default
rules:
 - apiGroups: [ ]
 resources: [endpoints]
 verbs: [get ,  list ,  watch ,  create ,  update ,  patch]
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: leader-locking-nfs-client-provisioner
 # replace with namespace where provisioner is deployed
 namespace: default
subjects:
 - kind: ServiceAccount
 name: nfs-client-provisioner
 # replace with namespace where provisioner is deployed
 namespace: default
roleRef:
 kind: Role
 name: leader-locking-nfs-client-provisioner
 apiGroup: rbac.authorization.k8s.io

部署存儲插件

動態卷供應的實現基于 storage.k8s.io API 組中的 StorageClass API 對象。集群管理員可以根據需要定義多個 StorageClass 對象，每個對象指定一個存儲插件（又名 provisioner），存儲插件以 Pod 的形式存在于 Kubernetes 集群中：

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nfs-client-provisioner
 labels:
 app: nfs-client-provisioner
 # replace with namespace where provisioner is deployed
 namespace: default
spec:
 replicas: 1
 strategy:
 type: Recreate
 selector:
 matchLabels:
 app: nfs-client-provisioner
 template:
 metadata:
 labels:
 app: nfs-client-provisioner
 spec:
 serviceAccountName: nfs-client-provisioner
 containers:
 - name: nfs-client-provisioner
 image: quay.io/external_storage/nfs-client-provisioner:latest
 volumeMounts:
 - name: nfs-client-root
 mountPath: /persistentvolumes
 env:
 #  指定標識插件的值
 - name: PROVISIONER_NAME
 value: fuseim.pri/ifs # 匹配 StorageClass 的 provisioner
 - name: NFS_SERVER
 value: 10.0.1.31 #NFS 服務器的 ip 地址
 - name: NFS_PATH
 value: /storage #NFS 服務器的路徑
 volumes:
 - name: nfs-client-root
 nfs:
 server: 10.0.1.31 #NFS 服務器的 ip 地址
 path: /storage #NFS 服務器的路徑

方式一：創建 PVC 自動申請 PV 配置 StorageClass

StorageClass 聲明存儲插件，用于自動創建 PV，provisioner 參數和存儲插件的標識對應上才能動態供應卷：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: managed-nfs-storage
provisioner: fuseim.pri/ifs # 要匹配 nfs deployment env PROVISIONER_NAME 的值，默認不支持 nfs 存儲需要添加插件標識
parameters:
 archiveOnDelete:  false

創建 PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: nginx-pv-storage
spec:
 accessModes:
 - ReadWriteMany
 storageClassName: managed-nfs-storage
 resources:
 requests:
 storage: 1Gi

查看創建的 PVC 和 PV，可以看到我們只創建了 PVC，PV 是存儲插件自動配置的

root@master01:~/yaml/storageClass# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
nginx-pv-storage Bound pvc-e52ac960-182a-4065-a6e8-6957f5c93b8a 1Gi RWX managed-nfs-storage 3s
root@master01:~/yaml/storageClass# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-e52ac960-182a-4065-a6e8-6957f5c93b8a 1Gi RWX Delete Bound default/nginx-test managed-nfs-storage 11s

Pod 使用 PVC 申請 Volume：

apiVersion: v1
kind: Pod
metadata:
 name: nginx-pv-pod
spec:
 volumes:
 - name: nginx-pv-storage
 persistentVolumeClaim:
 claimName: nginx-test
 containers:
 - name: nginx-pv-container
 image: nginx
 ports:
 - containerPort: 80
 name:  nginx-server 
 volumeMounts:
 - mountPath:  /usr/share/nginx/html 
 name: nginx-pv-storage

方式二：volumeClaimTemplates

除了上面創建 PVC 自動創建 PV，然后 Pod 再聲明使用 PVC 的方式以外，還有一個更簡便的方法，就是使用 volumeClaimTemplates 直接指定 StorageClass 和申請存儲的大小，動態創建 PVC 和 PV：

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web
spec:
 selector:
 matchLabels:
 app: nginx
 serviceName:  nginx 
 replicas: 2
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx
 image: nginx
 ports:
 - containerPort: 80
 name: web
 volumeMounts:
 - name: nginx-disk-ssd
 mountPath: /data
 volumeClaimTemplates:
 - metadata:
 name: nginx-disk-ssd
 spec:
 accessModes: [  ReadWriteOnce  ]
 storageClassName:  managed-nfs-storage  #storageClass 的名字
 resources:
 requests:
 storage: 10Gi

到此，相信大家對“Kubernetes 持久卷怎么使用”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！

正文完