DevOps CICD K8s DockerA 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及PVCbind起來,每個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