DevOps
CICD
K8s
Docker
A pod definition file is created at q9-pod.yaml. Make use of this manifest file and mount the persistent volume
called pv-1. Ensure the pod is running and the PV is bound.
mountPath: /data persistentVolumeClaim Name: my-pvc
這題是個Persistent Volume
和Persistent Volume Claim
的題目。先來看一下這兩個是甚麼東東吧~
前幾天我們有提到Volume
這個概念,當Pod使用Volume
時,需要在Pod YAML中定義Volume
的configuration。隨著K8s的集群環境增大,大量的使用者需求佈署大量的Pod,這樣就會導致一個情況,那就是使用者每次創建一個Pod時都需要為Pod重新config一個Volume
。當某個Volume
被某一使用者使用了,所有Pod的configuration file都需要重新config,如此就會讓整個集群的運作非常沒有效率,因此需要有個集中式管理的storage solution,方法類似讓集群管理者可以創建一個storage pool
,使用者根據需求從storage pool
中擷取一部分使用,這就是Persistent Volumes(PV)
& Persistent Volumes Claim(PVC)
和的功能啦~
Persistent Volumes(PV)
是一個pool of Volumes
,由集群管理者創造給整個集群使用。使用者可以透過Persistent Volumes Claim(PVC)
在PV
上選擇一個區塊作為storage
儲存資料,並在其中佈署自己的Applications。
可以把
PV
想像成一個100G的Memory,User1以PVC
拿了其中的10G,User2也以PVC
拿了其中的20G,這樣PV
中的Memory就剩下70G。PV
就是一個公共儲存空間,要使用這個公共空間,就要搭配PVC
使用
下面是PV
的範例YAML:
$ cat pv-def.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
hostPath:
path: /tmp/data
capacity
:定義這個PV
的storage大小。
accessModes
:PV
可以通過資源提供者支援的任何方式安裝在host上。每個PV
的存取模式會設置為該Volume
支援的特定模式。每個PV
都有自己的一組訪問模式,用於描述該特定PV
的功能。分為三種:
ReadWriteOnce
:通過單一節點以read-write方式掛載ReadWriteMany
:通過多節點以read-write方式掛載ReadOnlyMany
:通過多節點以read-only模式掛載
PV
和PVC
是兩個獨立的object,由adminstrator創造PV
;PVC
則由使用者創造,用以使用PV
當PV
和PVC
創建完成後,K8s會根據PVC
的request和PV
的properties,將最合適的PV
及PVC
bind起來,每個PVC
只會bound一個PV
。在binding過程中,K8s會為PVC
挑選最合適的PV
,除了容量外,也會考量accessModes
、vloumeModes
和storage class
等等。
當然你若想binding到特別的
PV
,也可以透過我們前面介紹過的label
下面是PVC
的範例YAML:
$ vim pvc-def.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Mi
當創建此PVC
後,可能會看見它處於Pending Status
,這是因為沒有找到合適配對的PV
。接著創建PV
後,K8s會自動將兩者binding起來,就可以看見PVC
是Bound Status
囉~
那Pod要如何搭配PVC
使用,可以參考下面YAML:
$ cat pod-pvc.yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: nginx
volumeMounts:
- mountPath: "/var/data"
name: myvm
volumes:
- name: myvm
persistentVolumeClaim:
claimName: myclaim
回到題目,這題用到的就是PV
和PVC
的概念,首先這題已經有個Pod的YAML和running的PV
,那我們需要做的就是:
PVC
,讓PV
被此PVC
bound住PVC
首先,系統環境已經創建了一個Pod的YAML,定義如下:
$ cat q9-pod.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: q9-pod
name: q9-pod
spec:
containers:
- image: nginx
name: q9-pod
resources: {}
dnspolicy: ClusterFirst
restartPolicy: Always
status: {}
除此之外,還有一個一經在runing的PV
,名為pv-1
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-1 10Mi RWO Retain Available 15m
PV
處於Available Status
,代表目前沒有PVC
存在,或是沒有合適的PVC
可以bind此PV
,那我們就需要自己建一個。
$ vim q9-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
## 大小設置剛好配對PV
storage: 10Mi
## 創建此PVC
$ kubectl apply -f q9-pvc.yaml
persistentvolumeclaim/my-pvc created
## 等個幾秒,確認PV已經被bound住
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-1 10Mi RWO Retain Bound default/my-pvc
接著,將PVC作為volume,mount在系統給的範例Pod上
$ vim q9-pod.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: q9-pod
name: q9-pod
spec:
containers:
- image: nginx
name: q9-pod
volumeMounts:
- mountPath: "/data"
name: mypd
resources: {}
volumes:
- name: mypd
persistentVolumeClaim:
claimName: my-pvc
dnspolicy: ClusterFirst
restartPolicy: Always
status: {}
## 創建Pod
$ kubectl apply -f q9-pod.yaml
這題介紹到PV
和PVC
的概念,算是前面Volume
相關的主題延伸,也更符合實際應用場景,不知道大家有沒有更了解一點了!好啦,今天就到這囉~ 謝謝大家~
Persistent Volumes
Day 15 - 別再遺失資料了:Volume (2)
You can find me on