學(xué)習(xí)了PV的使用，但是我們真正使用的是PVC暴氏，就類似于我們的服務(wù)是通過(guò)pod來(lái)運(yùn)行的答渔，而不是Node，只是pod跑在Node上而已宋雏。
準(zhǔn)備工作
在使用pvc之前磨总，我們還得把其他節(jié)點(diǎn)上的nfs客戶端安裝上，
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
master Ready master 61d v1.10.0
node01 Ready <none> 61d v1.10.0
node03 Ready <none> 41d v1.10.0
我們需要在所有節(jié)點(diǎn)安裝nfs客戶端程序娶牌。必須安裝nfs客戶端，否則可能會(huì)導(dǎo)致PV掛載不上的問(wèn)題鉴裹。
新建PVC
我們新建一個(gè)數(shù)據(jù)卷聲明壹罚，我們來(lái)請(qǐng)求1Gi的存儲(chǔ)容量猖凛，訪問(wèn)模式也是ReadWriteOnce，YAML文件如下：（pvc-nfs.yaml）
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-nfs
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
我們可以看出到我們這里的聲明方式幾乎和新建PV是一樣的菠红，在新建的PVC之前，我們可以看下之前創(chuàng)建的PV的狀態(tài)：
kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-nfs 1Gi RWO Recycle Available
我們可以看到當(dāng)前pv-nfs是在Available的一個(gè)狀態(tài)遇绞，所以這個(gè)時(shí)候我們的PVC可以和這個(gè)PV進(jìn)行綁定：
$ kubectl create -f pvc-nfs.yaml
persistentvolumeclaim "pvc-nfs" created
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs Bound pv-nfs 1Gi RWO 12s
我們可以看到PVC-nfs創(chuàng)建成功了，狀態(tài)是Bound狀態(tài)了付鹿，這個(gè)時(shí)候我們?cè)倏聪聀v狀態(tài)：
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-nfs 1Gi RWO Recycle Bound default/pvc-nfs
同樣我們可以看到PV也是Bound狀態(tài)了俊抵，對(duì)應(yīng)的聲明是default/pvc-nfs务蝠，就是default命名空間下面的pvc-nfs烛缔，證明我們剛剛新建的pvc-nfs和我們的pv-nfs綁定成功了践瓷。
我們并沒(méi)有在pvc-nfs中指定關(guān)于pv的什么標(biāo)志晕翠，他們之間是怎么就關(guān)聯(lián)起來(lái)了的了？其實(shí)這是系統(tǒng)自動(dòng)幫我們?nèi)テヅ涞牧蚵椋鼤?huì)根據(jù)我們的聲明要求去查找處于Available狀態(tài)的PV拿愧，如果沒(méi)有找到的話那么我們的PVC就會(huì)一直處于Pending狀態(tài)碌尔，找到了的話當(dāng)然就會(huì)把當(dāng)前的PVC和目標(biāo)PV進(jìn)行綁定唾戚，這個(gè)時(shí)候狀態(tài)就會(huì)變成Bound狀態(tài)了。比如我們新建pvc（pvc2-nfs.yaml）:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc2-nfs
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
selector:
matchLabels:
app: nfs
我們這里聲明一個(gè)PV資源的請(qǐng)求熊镣，邀請(qǐng)?jiān)L問(wèn)模式是ReadWriteOnce轧钓，存儲(chǔ)容量是2Gi锐膜，最后我們還要求匹配具有標(biāo)簽app=nfs的pv道盏，這樣的要求的PV有嗎荷逞？
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-nfs 1Gi RWO Recycle Bound default/pvc-nfs 43m
pv001 1Gi RWO Recycle Bound default/www-web-0 13d
pv002 1Gi RWO Recycle Bound default/www-web-1
都是Bound狀態(tài)，并沒(méi)有Available狀態(tài)的PV涩澡，所以我們可以想象到我們上面新建的PVC是沒(méi)辦法選擇到合適的PV的
$ kubectl create -f pvc2-nfs.yaml
persistentvolumeclaim "pvc2-nfs" created
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs Bound pv-nfs 1Gi RWO 23m
pvc2-nfs Pending
很顯然是pending狀態(tài)妙同，因?yàn)椴](méi)有合適的PV給你使用粥帚，現(xiàn)在我們來(lái)新建一個(gè)PV限次，讓上面的PVC有合適的PV使用（pv2-nfs.yaml）:
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv2-nfs
labels:
app: nfs
spec:
capacity:
storage: 2Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
nfs:
server: 10.151.30.57
path: /data/k8s
我們這里新建一個(gè)名為pv2-nfs的pv卖漫，具有標(biāo)簽app=nfs羊始，容量也是2Gi，訪問(wèn)模式是ReadWriteOnce速警，看上去這一切都很適合上面的PVC闷旧，新建試一試：
$ kubectl create -f pv2-nfs.yaml
persistentvolume "pv2-nfs" created
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-nfs 1Gi RWO Recycle Bound default/pvc-nfs 51m
pv2-nfs 2Gi RWO Recycle Bound default/pvc2-nfs
成功了忙灼，對(duì)吧钝侠！有的同學(xué)可能又會(huì)說(shuō)了帅韧，我們的 pv2-nfs 聲明的容量是 2Gi，如果我 pvc2-nfs 這里聲明的容量是 1Gi 的話呢双妨？還能正常綁定嗎刁品？如果可以正常綁定的話，那剩下的 1Gi 容量還能使用嗎？其實(shí)我也不清楚膏孟，怎么辦担猛？我們?nèi)?shí)際測(cè)試下就知道了吧先改，先刪除上面的 pvc2-nfs，然后我們把該 PVC 里面的容量改成 1Gi，再新建試一試呢：
$ kubectl delete pvc pvc2-nfs
persistentvolumeclaim "pvc2-nfs" deleted
$ cat pvc2-nfs.yaml
...
resources:
requests:
storage: 1Gi
...
$ kubectl create -f pvc2-nfs.yaml
persistentvolumeclaim "pvc2-nfs" created
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc2-nfs Bound pv2-nfs 2Gi RWO 7s
我們可以看到上面的 PVC 依然可以正常的綁定，仔細(xì)看 CAPACITY 這一列的數(shù)據(jù)：2Gi氯庆，也就是說(shuō)我們聲明的 1Gi 是沒(méi)什么用的，我 PV 是 2Gi，你這里聲明 1Gi 是不行的族跛，你必須得使用 2Gi长酗。
如果我們這里容量聲明是 3Gi 呢之拨？還可以正常綁定嗎？大家可以思考一下，如果聲明的容量大于了 PV 里面的容量的話睬魂，是沒(méi)辦法進(jìn)行綁定的，大家可以下去自己測(cè)試一下。
使用 PVC
上面我們已經(jīng)知道怎么創(chuàng)建 PV 和 PVC 了，現(xiàn)在我們就來(lái)使用下我們的 PVC舔痕，這里我們同樣使用之前的 nginx 的鏡像來(lái)測(cè)試下：(nfs-pvc-deploy.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-pvc
spec:
replicas: 3
selector:
matchLabels:
app: nfs-pvc
template:
metadata:
labels:
app: nfs-pvc
spec:
containers:
- name: nginx
image: nginx:1.7.9
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumes:
- name: www
persistentVolumeClaim:
claimName: pvc2-nfs
---
apiVersion: v1
kind: Service
metadata:
name: nfs-pvc
labels:
app: nfs-pvc
spec:
type: NodePort
ports:
- port: 80
targetPort: web
selector:
app: nfs-pvc
我們這里使用 nginx 鏡像啸如，將容器的 /usr/share/nginx/html 目錄通過(guò) volume 掛載到名為 pvc2-nfs 的 PVC 上面想暗，然后創(chuàng)建一個(gè) NodePort 類型的 Service 來(lái)暴露服務(wù)：
$ kubectl create -f nfs-pvc-deploy.yaml
deployment.extensions "nfs-pvc" created
service "nfs-pvc" created
$ kubectl get pods
kubectl get pods
NAME READY STATUS RESTARTS AGE
...
nfs-pvc-57c9945bd9-5r4r6 1/1 Running 0 19s
nfs-pvc-57c9945bd9-gz6p9 1/1 Running 0 19s
nfs-pvc-57c9945bd9-x6mvc 1/1 Running 0 19s
...
$ kubectl get svc
kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
...
nfs-pvc NodePort 10.98.246.155 <none> 80:30769/TCP 1m
...
然后我們就可以通過(guò)任意節(jié)點(diǎn)的 IP:30769 端口來(lái)訪問(wèn)我們這里的 Nginx 服務(wù)了储狭，但是這個(gè)時(shí)候我們來(lái)訪問(wèn)會(huì)出現(xiàn)403，這是為什么？我們?cè)偃タ纯?nfs 共享數(shù)據(jù)目錄下面有沒(méi)有數(shù)據(jù)呢着茸？
$ ls /data/k8s
我們發(fā)現(xiàn)并沒(méi)有任何數(shù)據(jù)旋膳，這是因?yàn)槲覀儼讶萜髂夸?strong>/user/share/nginx/html和掛載到了pvc2-nfs這個(gè) PVC 上面验懊，這個(gè) PVC 就是對(duì)應(yīng)著我們上面的 nfs 的共享數(shù)據(jù)目錄的，該目錄下面還沒(méi)有任何數(shù)據(jù)减俏，所以我們?cè)L問(wèn)就出現(xiàn)了403娃承，現(xiàn)在我們?cè)?strong>/data/k8s這個(gè)目錄下面新建一個(gè) index.html 的文件：
$ echo "<h1>Hello Kubernetes~</h1>" >> /data/k8s/index.html
$ ls /data/k8s/
index.html
我們可以看到共享數(shù)據(jù)目錄中已經(jīng)有一個(gè) index.html 的文件了历筝，由于我們掛載了 pvc2-nfs 到上面的 nginx 容器中去梳猪，是不是這個(gè)時(shí)候容器目錄/user/share/nginx/html下面也有index.html這個(gè)文件了按好帧？所以這個(gè)時(shí)候我們?cè)賮?lái)訪問(wèn)下服務(wù)扫责，任一節(jié)點(diǎn)IP:30769：
現(xiàn)在是不是正常了啊公给，但是我們可以看到我們?nèi)萜髦械臄?shù)據(jù)是直接放到共享數(shù)據(jù)目錄根目錄下面的，如果以后我們又有一個(gè)新的 nginx 容器也做了數(shù)據(jù)目錄的掛載蔫缸，是不是就會(huì)有沖突了啊拾碌，所以這個(gè)時(shí)候就不太好區(qū)分了校翔，這個(gè)時(shí)候我們可以在 Pod 中使用一個(gè)新的屬性：subPath防症，該屬性可以來(lái)解決這個(gè)問(wèn)題哎甲，我們只需要更改上面的 Pod 的 YAML 文件即可：
...
volumeMounts:
- name: www
subPath: nginxpvc-test
mountPath: /usr/share/nginx/html
...
更改完 YAML 文件后炭玫，我們重新更新即可：
$ kubectl apply -f nfs-pvc-deploy.yaml
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
deployment.extensions "nfs-pvc" configured
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
service "nfs-pvc" configured
更新完后吞加，我們?cè)偃タ纯?nfs 的數(shù)據(jù)共享目錄：
$ ls /data/k8s/
index.html nginxpvc-test
$ ls /data/k8s/nginxpvc-test/
我們可以預(yù)想到現(xiàn)在我們?cè)L問(wèn)上面的服務(wù)衔憨，是不是又會(huì)得到403的結(jié)果啊，因?yàn)?strong>nginxpvc-test目錄下面還沒(méi)有任何文件呢盗似，我們把根目錄下面的 index.html 文件移動(dòng)到 nginxpvc-test 目錄下面去是不是又可以訪問(wèn)了：
$ mv /data/k8s/index.html /data/k8s/nginxpvc-test/
現(xiàn)在快去驗(yàn)證下吧赫舒，看看能不能得到正確結(jié)果。
到這里我們就算完整的使用了一次 PVC 了心赶，現(xiàn)在我們?cè)賮?lái)驗(yàn)證下我們的數(shù)據(jù)是否會(huì)丟失缨叫，怎么驗(yàn)證荔燎？首先我們把上面的 Deployment 刪除掉，這樣是不是他下面管理的3個(gè) Pod 也會(huì)被一起刪除掉八龃亍：
$ kubectl delete deployment nfs-pvc
deployment.extensions "nfs-pvc" deleted
Deployment 被刪除掉了婉商，但是 nfs 的數(shù)據(jù)共享目錄下面的數(shù)據(jù)呢渣叛？
$ ls /data/k8s/nginxpvc-test/
index.html
還在吧？當(dāng)然了如果不在了蘑秽，我們用他就沒(méi)有任何意義了吧筷狼，現(xiàn)在我們?cè)賮?lái)重新創(chuàng)建上面的 Deployment匠童，看看訪問(wèn)服務(wù)還能得到上面的正常輸出結(jié)果嗎：
$ kubectl create -f nfs-pvc-deploy.yaml
deployment.extensions "nfs-pvc" created
Error from server (AlreadyExists): error when creating "nfs-pvc-deploy.yaml": services "nfs-pvc" already exists
可以看到 nfs-pvc 這個(gè) Deployment 創(chuàng)建成功了汤求，由于 Service 我們之前沒(méi)有刪除掉扬绪，所以這里提示已經(jīng)存在，我們忽略就可以了莹痢，現(xiàn)在同樣我們用任一節(jié)點(diǎn) IP:30769 來(lái)訪問(wèn)我們這里的服務(wù)竞膳，是不是依然可以在頁(yè)面上看到Hello Kubernetes~這里的輸出信息啊坦辟，這證明我們的數(shù)據(jù)持久化是成功的吧！
注意事項(xiàng)
上面我們演示了數(shù)據(jù)持久化滨彻，如果這個(gè)時(shí)候我們把 PV 給刪除了亭饵，上面持久化的數(shù)據(jù)還會(huì)存在嗎冬骚？如果是刪除的 PVC 呢懂算？在實(shí)際使用的工程中计技，是很有可能出現(xiàn)這種情況的吧垮媒？下面我們來(lái)實(shí)際驗(yàn)證下睡雇。
我們先刪除上面使用的 PV：
$ kubectl delete pv pv2-nfs
persistentvolume "pv2-nfs" deleted
然后再看看之前創(chuàng)建的 PVC 還會(huì)存在嗎：
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
...
pvc2-nfs Bound pv2-nfs 2Gi RWO 1h
...
是不是覺(jué)得很奇怪饮醇，pvc2-nfs 仍然是 Bound 的狀態(tài)朴艰，也就意外著我們還可以正常使用這個(gè) PVC，但是如果我們有一個(gè)新的 Pod 來(lái)使用這個(gè) PVC 會(huì)是怎樣的情況呢侮穿？大家下去自己驗(yàn)證下
如有 Pod 正在使用此 pvc2-nfs 這個(gè) PVC 的話亲茅，那么新建的 Pod 則仍可使用，如無(wú) Pod 使用茵肃，則創(chuàng)建 Pod 掛載此 PVC 時(shí)會(huì)出現(xiàn)失敗娶耍。大家自己去驗(yàn)證下吧
現(xiàn)在我們?cè)诨謴?fù)到最開(kāi)始的狀態(tài)榕酒，把 PV 和 PVC 添加回來(lái)，如果現(xiàn)在我們把使用 pvc2-nfs 關(guān)聯(lián)的 Pod 都刪除紊婉，然后再刪除該 PVC 的話喻犁，那么我們的持久化數(shù)據(jù)還存在嗎肢础？
$ kubectl delete -f nfs-pvc-deploy.yaml
deployment.extensions "nfs-pvc" deleted
service "nfs-pvc" deleted
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
...
pvc2-nfs Bound pv2-nfs 2Gi RWO 5m
...
$ kubectl delete pvc pvc2-nfs
persistentvolumeclaim "pvc2-nfs" deleted
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
...
pv2-nfs 2Gi RWO Recycle Released default/pvc2-nfs 6m
...
$ ls /data/k8s/
我們可以看到 pv2-nfs 這個(gè) PV 的狀態(tài)已經(jīng)變成了 Released 狀態(tài)了传轰，這個(gè)狀態(tài)是不是表示 PVC 已經(jīng)被釋放了慨蛙，現(xiàn)在可以被重新綁定了期贫，由于我們?cè)O(shè)置的 PV 的回收策略是 Recycle通砍，所以我們可以很明顯的發(fā)現(xiàn) nfs 的共享數(shù)據(jù)目錄下面已經(jīng)沒(méi)有了數(shù)據(jù)了烤蜕，這是因?yàn)槲覀儼?PVC 給刪除掉了玖绿，然后回收了數(shù)據(jù)斑匪。
不過(guò)大家要注意，并不是所有的存儲(chǔ)后端的表現(xiàn)結(jié)果都是這樣的庶橱，我們這里使用的是 nfs贪惹，其他存儲(chǔ)后端肯能會(huì)有不一樣的結(jié)果奏瞬。
大家在使用 PV 和 PVC 的時(shí)候一定要注意這些細(xì)節(jié)，不然一不小心就把數(shù)據(jù)搞丟了并淋。
