出處:https://www.cnblogs.com/qiuhom-1874/
volume的基礎使用,需要我們使用者手動來向不同型別儲存介面傳遞不同的引數,從而實現把外部儲存對映到k8s上的一個volume物件,使得pod才能正常的掛載對應的儲存卷,對應pod裡的容器才能正常使用;這種使用方式的前提是使用者必須瞭解對應的儲存系統,瞭解對應型別的儲存介面,以及相關引數;這使得使用者在k8s上使用儲存卷變得有些複雜;為了簡化這一過程,在k8s上使用pv和pvc資源來把對應底層儲存介面給隱藏了,使用者使用儲存卷不再關心底層儲存系統介面;不管底層是哪種型別的儲存,使用者只需面對一個pvc介面即可;
PV、PVC和K8s叢集以及pod的關係
提示:使用者在建立pod時使用儲存卷只需要關心對應名稱空間的pvc物件;而對應pv是需要叢集管理管理員定義;後端儲存是專門的儲存管理員負責管理;pv是k8s上的一種標準資源,全稱叫做PersistentVolume翻譯成中文就是持久儲存卷;它主要作用是把後端儲存中的某個邏輯單元,對映為k8s上的pv資源;pv是叢集級別的資源;任意名稱空間都可以直接關聯某一個pv;關聯pv的過程我們叫做繫結pv;而對應名稱空間關聯某一pv需要使用pvc資源來定義;pvc全稱PersistentVolumeClaim的縮寫,意思就是持久儲存卷申請;在一個名稱空間下建立一個pvc就是把對應名稱空間同叢集上的某一pv做繫結;一旦一個名稱空間綁定了一個pv後,對應的pv就會從available狀態轉變成bond狀態,其他名稱空間將不能再使用,只有對應pv是available狀態才能正常的被其他名稱空間關聯繫結;簡單講pvc和pv的關係是一一對應的,一個pv只能對應一個pvc;至於同一名稱空間下的多個pod是否能夠同時使用一個PVC取決pv是否允許多路讀寫,對應pv是否支援多路讀寫取決後端儲存系統;不同型別的儲存系統,對應訪問模式也有所不同。訪問模式有三種,單路讀寫(ReadWriteOnce簡稱RWO),多路讀寫(ReadWriteMany簡稱RWX),多路只讀(ReadOnlyMany簡稱ROX);
示例:pv資源建立
[root@master01 ~]# cat pv-v1-demo.yaml apiVersion: v1kind: PersistentVolumemetadata: name: nfs-pv-v1 labels: storsystem: nfs-v1 rel: stablespec: capacity: storage: 1Gi volumeMode: Filesystem accessModes: ["ReadWriteOnce","ReadWriteMany","ReadOnlyMany"] persistentVolumeReclaimPolicy: Retain mountOptions: - hard - nfsvers=4.1 nfs: path: /data/v1 server: 192.168.0.99[root@master01 ~]#
提示:pv是k8s的標準資源,其群組版本為v1,型別為PersistentVolume;spec.capacity.storage欄位用來描述pv的儲存容量;volumeMode用來描述對應儲存系統提供的儲存卷型別介面,一般儲存卷型別介面有兩種,分別是檔案系統介面和塊裝置介面;accessModes用來描述pv的訪問模式;presistentVolumeReclaimPolicy欄位用來描述儲存捲回收策略,持久捲回收策略有3中,一種是Delete,表示當pvc刪除以後,對應pv也隨之刪除;第二種是Recycle,表示當pvc刪除以後,對應pv的資料也隨之被刪除;第三種是Retain表示當pvc被刪除以後,pv原封動,即pv也在,對應資料也在;mountOptions欄位用來指定掛載選項;nfs表示後端儲存為nfs,對於不同型別的儲存,對應的要傳遞的引數各不相同,對於nfs這種型別的儲存,我們只需要指定其nfs伺服器地址以及對應共享出來的檔案路徑;以上配置就表示把nfs上的/data/v1目錄對映到k8s上的pv,對應pv的名稱為nfs-pv-v1;這裡需要注意一點,在建立pv時,對應後端儲存應該提前準備好;
應用配置清單
[root@master01 ~]# kubectl apply -f pv-v1-demo.yamlpersistentvolume/nfs-pv-v1 created[root@master01 ~]# kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEnfs-pv-v1 1Gi RWO,ROX,RWX Retain Available 4s[root@master01 ~]# kubectl describe pv nfs-pv-v1Name: nfs-pv-v1Labels: rel=stable storsystem=nfs-v1Annotations: <none>Finalizers: [kubernetes.io/pv-protection]StorageClass: Status: AvailableClaim: Reclaim Policy: RetainAccess Modes: RWO,ROX,RWXVolumeMode: FilesystemCapacity: 1GiNode Affinity: <none>Message: Source: Type: NFS (an NFS mount that lasts the lifetime of a pod) Server: 192.168.0.99 Path: /data/v1 ReadOnly: falseEvents: <none>[root@master01 ~]#
提示:在pv的詳細資訊中能夠看到,當前pv的狀態為available,pv對應後端的儲存是nfs,對應儲存的ip地址為192.168.0.99,當前pv對應後端儲存的邏輯單元就是/data/v1;
示例:建立pvc
[root@master01 ~]# cat pvc-v1-demo.yaml apiVersion: v1kind: PersistentVolumeClaimmetadata: name: pvc-nfs-pv-v1 namespace: default labels: storsystem: nfs-v1spec: accessModes: - ReadWriteMany volumeMode: Filesystem resources: requests: storage: 500Mi selector: matchLabels: storsystem: nfs-v1 rel: stable[root@master01 ~]#
提示:pvc也是k8s上的標準資源,對應的群組版本為v1,型別為PersistentVolumeClaim;其中spec.accessModes欄位是用來指定其pvc的訪問模式,一般這個模式是被pv的accessModes包含,也就說pvc的訪問模式必須是pv的子集,即等於小於pv的訪問模式;resources用來描述對應pvc的儲存空間限制,requests用來描述對應pvc最小容量限制,limits用來描述最大容量限制;selector用來定義標籤選擇器,主要作用過濾符合對應標籤的pv;如果不定義標籤選擇器,它會在所有available狀態的pv中,透過其容量大小限制以及訪問模式去匹配一個最佳的pv進行關聯;
應用配置清單
[root@master01 ~]# kubectl apply -f pvc-v1-demo.yaml persistentvolumeclaim/pvc-nfs-pv-v1 created[root@master01 ~]# kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpvc-nfs-pv-v1 Bound nfs-pv-v1 1Gi RWO,ROX,RWX 8s[root@master01 ~]# kubectl describe pvc pvc-nfs-pv-v1Name: pvc-nfs-pv-v1Namespace: defaultStorageClass: Status: BoundVolume: nfs-pv-v1Labels: storsystem=nfs-v1Annotations: pv.kubernetes.io/bind-completed: yes pv.kubernetes.io/bound-by-controller: yesFinalizers: [kubernetes.io/pvc-protection]Capacity: 1GiAccess Modes: RWO,ROX,RWXVolumeMode: FilesystemUsed By: <none>Events: <none>[root@master01 ~]# kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEnfs-pv-v1 1Gi RWO,ROX,RWX Retain Bound default/pvc-nfs-pv-v1 19m[root@master01 ~]#
提示:這裡顯示pvc的大小是pvc最大容量顯示,預設不限制最大容量就是其pv的最大容量;從上面的顯示可以看到對應pv被pvc繫結以後,其狀態就變成了bound;
示例:建立pod關聯pvc,並在其pod容器裡掛載pvc
[root@master01 ~]# cat redis-demo.yamlapiVersion: v1kind: Podmetadata: name: redis-demo labels: app: redisspec: containers: - name: redis image: redis:alpine volumeMounts: - mountPath: /data name: redis-data volumes: - name: redis-data persistentVolumeClaim: claimName: pvc-nfs-pv-v1[root@master01 ~]#
提示:在pod裡關聯pvc,只需要指定後端儲存型別為persistentVolumeClaim,然後指定對應的pvc名稱;
應用資源清單
[root@master01 ~]# kubectl apply -f redis-demo.yamlpod/redis-demo created[root@master01 ~]# kubectl get podNAME READY STATUS RESTARTS AGEredis-demo 0/1 ContainerCreating 0 7s[root@master01 ~]# kubectl get podNAME READY STATUS RESTARTS AGEredis-demo 1/1 Running 0 27s[root@master01 ~]# kubectl describe pod redis-demoName: redis-demoNamespace: defaultPriority: 0Node: node03.k8s.org/192.168.0.46Start Time: Fri, 25 Dec 2020 21:55:41 +0800Labels: app=redisAnnotations: <none>Status: RunningIP: 10.244.3.105IPs: IP: 10.244.3.105Containers: redis: Container ID: docker://8e8965f52fd0144f8d6ce68185209114163a42f8437d7d845d431614f3d6dd05 Image: redis:alpine Image ID: docker-pullable://redis@sha256:68d4030e07912c418332ba6fdab4ac69f0293d9b1daaed4f1f77bdeb0a5eb048 Port: <none> Host Port: <none> State: Running Started: Fri, 25 Dec 2020 21:55:48 +0800 Ready: True Restart Count: 0 Environment: <none> Mounts: /data from redis-data (rw) /var/run/secrets/kubernetes.io/serviceaccount from default-token-xvd4c (ro)Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: redis-data: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) ClaimName: pvc-nfs-pv-v1 ReadOnly: false default-token-xvd4c: Type: Secret (a volume populated by a Secret) SecretName: default-token-xvd4c Optional: falseQoS Class: BestEffortNode-Selectors: <none>Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300sEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 37s default-scheduler Successfully assigned default/redis-demo to node03.k8s.org Normal Pulling 36s kubelet Pulling image "redis:alpine" Normal Pulled 30s kubelet Successfully pulled image "redis:alpine" in 5.284107704s Normal Created 30s kubelet Created container redis Normal Started 30s kubelet Started container redis[root@master01 ~]#
提示:可以看到對應pod已經正常執行起來;從詳細資訊中可以看到對應pod使用的volumes型別為PersistentVolumeClaim,對應名稱為pvc-nfs-pv-v1;對應容器以讀寫方式掛載了對應儲存卷;
測試:在redis-demo上產生資料,看看是否能夠正常儲存到nfs伺服器上?
[root@master01 ~]# kubectl get podNAME READY STATUS RESTARTS AGEredis-demo 1/1 Running 0 5m28s[root@master01 ~]# kubectl exec -it redis-demo -- /bin/sh/data # redis-cli 127.0.0.1:6379> set mykey "this is test key "OK127.0.0.1:6379> get mykey"this is test key "127.0.0.1:6379> BGSAVEBackground saving started127.0.0.1:6379> exit/data # lsdump.rdb/data #
在nfs伺服器上檢視對應目錄下是否有dump.rdb檔案產生?
[root@docker_registry ~]# ll /data/v1total 4-rw-r--r-- 1 polkitd qiuhom 122 Dec 25 22:02 dump.rdb[root@docker_registry ~]#
提示:可以看到,redis上產生的快照檔案在nfs伺服器上有對應的檔案存在;
[root@master01 ~]# kubectl delete -f redis-demo.yaml pod "redis-demo" deleted[root@master01 ~]# kubectl get podsNo resources found in default namespace.[root@master01 ~]# ssh 192.168.0.99The authenticity of host '192.168.0.99 (192.168.0.99)' can't be established.ECDSA key fingerprint is SHA256:hQoossQnTJMXB0+DxJdTt6DMHuPFLDd5084tHyJ7920.ECDSA key fingerprint is MD5:ef:61:b6:ee:76:46:9d:0e:38:b6:b5:dd:11:66:23:26.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added '192.168.0.99' (ECDSA) to the list of known [email protected]'s password: Last login: Fri Dec 25 20:13:05 2020 from 192.168.0.232[root@docker_registry ~]# ll /data/v1total 4-rw-r--r-- 1 polkitd qiuhom 122 Dec 25 22:05 dump.rdb[root@docker_registry ~]# exitlogoutConnection to 192.168.0.99 closed.[root@master01 ~]#
提示:可以看到刪除了pod對應快照檔案在nfs伺服器還是存在;
繫結節點,重新新建pod,看看對應是否能夠自動應用快照中的資料?
[root@master01 ~]# cat redis-demo.yamlapiVersion: v1kind: Podmetadata: name: redis-demo labels: app: redisspec: nodeName: node01.k8s.org containers: - name: redis image: redis:alpine volumeMounts: - mountPath: /data name: redis-data volumes: - name: redis-data persistentVolumeClaim: claimName: pvc-nfs-pv-v1[root@master01 ~]# kubectl apply -f redis-demo.yamlpod/redis-demo created[root@master01 ~]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESredis-demo 0/1 ContainerCreating 0 8s <none> node01.k8s.org <none> <none>[root@master01 ~]# kubectl get pod -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESredis-demo 1/1 Running 0 21s 10.244.1.88 node01.k8s.org <none> <none>[root@master01 ~]#
提示:可以看到新建的pod被排程到node01上了;
進入對應pod,看看是否應用了其快照檔案中的資料?對應key是否能夠被應用到記憶體?
[root@master01 ~]# kubectl get podsNAME READY STATUS RESTARTS AGEredis-demo 1/1 Running 0 2m39s[root@master01 ~]# kubectl exec -it redis-demo -- /bin/sh/data # redis-cli 127.0.0.1:6379> get mykey"this is test key "127.0.0.1:6379> exit/data # ls dump.rdb/data # exit[root@master01 ~]#
提示:可以看到新建的pod能夠正常讀取到nfs上的快照檔案並應用到記憶體中;
檢視pvc狀態
[root@master01 ~]# kubectl delete pvc pvc-nfs-pv-v1persistentvolumeclaim "pvc-nfs-pv-v1" deleted^C[root@master01 ~]# kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpvc-nfs-pv-v1 Terminating nfs-pv-v1 1Gi RWO,ROX,RWX 34m[root@master01 ~]# kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpvc-nfs-pv-v1 Terminating nfs-pv-v1 1Gi RWO,ROX,RWX 34m[root@master01 ~]# kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpvc-nfs-pv-v1 Terminating nfs-pv-v1 1Gi RWO,ROX,RWX 34m[root@master01 ~]# kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEnfs-pv-v1 1Gi RWO,ROX,RWX Retain Bound default/pvc-nfs-pv-v1 52m[root@master01 ~]#
提示:可以看到現在pvc的狀態變成了terminating,但對應pvc還在並沒有被刪除;對應pv還處於繫結狀態;
[root@master01 ~]# kubectl get podNAME READY STATUS RESTARTS AGEredis-demo 1/1 Running 0 14m[root@master01 ~]# kubectl delete pod redis-demopod "redis-demo" deleted[root@master01 ~]# kubectl get pvcNo resources found in default namespace.[root@master01 ~]# kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEnfs-pv-v1 1Gi RWO,ROX,RWX Retain Released default/pvc-nfs-pv-v1 54m[root@master01 ~]#
提示:可以看到刪除對應pod以後,pvc就立即刪除了;對應pvc被刪除以後,對應pv的狀態就從bound狀態轉變為Released狀態,表示等待回收;我們在資源清單中使用的是Retain回收策略,pv和pvc都是我們人工手動回收;
[root@master01 ~]# kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEnfs-pv-v1 1Gi RWO,ROX,RWX Retain Released default/pvc-nfs-pv-v1 57m[root@master01 ~]# kubectl delete pv nfs-pv-v1persistentvolume "nfs-pv-v1" deleted[root@master01 ~]# kubectl get pvNo resources found[root@master01 ~]# ssh [email protected]'s password: Last login: Fri Dec 25 22:05:53 2020 from 192.168.0.41[root@docker_registry ~]# ll /data/v1total 4-rw-r--r-- 1 polkitd qiuhom 122 Dec 25 22:24 dump.rdb[root@docker_registry ~]# exitlogoutConnection to 192.168.0.99 closed.[root@master01 ~]#
提示:可以看到刪除了pv,對應快照檔案並沒有清除;
以上就是pv和pvc資源的用法,下面我們再來說一下sc資源
SC是StorageClass的縮寫,表示儲存類;這種資源主要用來對pv資源的自動供給提供介面;所謂自動供給是指使用者無需手動建立pv,在使用pvc時自動建立pv並關聯到對應pvc上;使用sc資源的前提是對應後端儲存必須支援rustfull型別介面的管理介面,並且pvc必須指定對應儲存類名稱來引用SC;簡單講SC資源就是用來為後端儲存提供自動建立pv的介面;如下圖
提示:使用sc動態建立pv,對應pvc必須也是屬於對應的sc;上圖主要描述了使用者在建立pvc時,引用對應的sc以後,對應sc會呼叫底層儲存系統的管理介面,建立對應的pv並關聯至對應pvc;
示例:建立sc資源
apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: slowprovisioner: kubernetes.io/glusterfsparameters: resturl: "http://127.0.0.1:8081" clusterid: "630372ccdc720a92c681fb928f27b53f" restauthenabled: "true" restuser: "admin" secretNamespace: "default" secretName: "heketi-secret" gidMin: "40000" gidMax: "50000" volumetype: "replicate:3"
提示:上述是官方文件中的一個示例,在建立sc資源時,對應群組是storage.k8s.io/v1,型別為StorageClass;provisioner欄位用於描述對應供給介面名稱;parameters用來定義向對應儲存管理介面要傳遞的引數;
在pvc資源中引用SC資源物件
apiVersion: v1kind: PersistentVolumeClaimmetadata: name: foo-pvc namespace: foospec: storageClassName: "slow" volumeName: foo-pv ...
提示:在建立pvc時用storageClassName欄位來指定對應的SC即可;
出處:https://www.cnblogs.com/qiuhom-1874/