當把pod删除了，那麼pod裡所有的資料也就沒有了
是以這個問題怎麼解決呢？配置卷
emptyDir
emptyDir: 本地卷，在實體機裡随機生成一個目錄
如果pod被删除，則實體機裡對應的目錄也會被删除，不是永久性存儲
先建立一個yaml模闆然後修改
定義卷的格式：
volumes:
- name:
emptyDir: {}
根據docker inspect ID查找到/xx,映射到實體機的此目錄
進入容器的/xx目錄下建立一個aa.txt檔案
Vms63上的挂載目錄下同樣的多出一個相同的檔案
删除對應pod，目錄也會被删除無法通路
hostPath
hostPath:類似于docker run -v /data:/xx
配置hostPath的檔案映射至/data目錄
成功映射到data目錄
當删除pod後，檢查/data目錄資料仍然還在，這裡不作示範
NFS
NFS:網絡卷
如果pod出問題導緻重新開機而從原本的節點運作至其他節點，這個時候新節點沒有原本節點的目錄導緻資料不一緻或者其他問題，怎麼辦？使用NFS網絡存儲
另外準備一台機器vms50作為存儲伺服器并安裝相關軟體包并設定rpcbind和nfs-server開機自啟
隻允許192.168.135.0/24這個網段來通路我的存儲且用root的權限不作任何壓縮
本次實驗用*表示允許任何用戶端通路，注意*與括号之間沒有空格
通過exportsfs -arv讓其生效
注：雖然是在pod上挂載的，但是必須在worker上 安裝用戶端，不然沒有showmount指令在所有節點安裝yum -y install nfs-u*
測試成功挂載
修改配置，192.168.135.50這個server下的/vdisk的目錄挂載到了/xx
進入容器後檢視，挂載成功
建立一個aa.txt，共享存儲上也成功同步
在/vdisk建立檔案，則容器裡也會同步出現相同檔案，這裡不作示範
到此nfs搭建完成，就算pod移至其他節點也不會影響資料一緻性
持久性存儲
PV是全局的，所有命名空間是可見的
ReadWriteOnce：同時隻有一個去讀寫
ReadOnlyMany：同時有多個去讀，不能寫
ReadWriteMany：同時有多個去讀寫
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv01
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
nfs:
path:/aa
server: 192.168.135.50
成功建立一個名為pv01的pv，狀态為available時pvc才能和pv進行關聯
所有命名空間都可檢視到，全局可見
通過kubectl describe pv pv01檢視詳細資訊
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mypvc1
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 5Gi
成功建立mypvc1并成功關聯pv01
accessModes必須一樣，且pvc大小要小于等于pv大小，兩者才能成功關聯
注：一個pv一次隻能和一個pvc進行關聯
以上的pv和pvc的storageClassName的值不一樣，導緻一直pending關聯不上
需要改成一樣的值才能關聯，這裡為節約篇幅不作示範
pv回收政策
• Recycle --會删除資料
• 會生成一個pod回收資料
• 删除pvc之後，pv可複用
• pv狀态由Released變為Available
• Retain--不回收資料
• 但是删除pvc之後，pv依然不可用
• pv狀态長期保持為 Released
修改回收政策為Retain後再删除pod就不會影響資料的丢失
官網原文：
A user creates, or has already created in the case of dynamic provisioning, a PersistentVolumeClaim with a specific amount of storage requested and with certain access modes.
A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together.
If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested.
Once bound, PersistentVolumeClaim binds are exclusive, regardless of how they were bound. A PVC to PV binding is a one-to-one mapping.