kubernetes 的pv/pvc存儲
標籤（空格分隔）： kubernetes系列
- 一： kubernetes的PV/PVC存儲
一： kubernetes的PV/PVC存儲
1.1 pv
PersistentVolume （PV）
是由管理員設置的存儲，它是羣集的一部分。就像節點是集羣中的資源一樣，PV 也是集羣中的資源。 PV 是
Volume 之類的卷插件，但具有獨立於使用 PV 的 Pod 的生命週期。此 API 對象包含存儲實現的細節，即 NFS、
iSCSI 或特定於雲供應商的存儲系統
1.2 pvc
PersistentVolumeClaim （PVC）
是用戶存儲的請求。它與 Pod 相似。Pod 消耗節點資源，PVC 消耗 PV 資源。Pod 可以請求特定級別的資源
（CPU 和內存）。聲明可以請求特定的大小和訪問模式（例如，可以以讀/寫一次或 只讀多次模式掛載）
1.3 靜態 pv
集羣管理員創建一些 PV。它們帶有可供羣集用戶使用的實際存儲的細節。它們存在於 Kubernetes API 中，可用
於消費1.4 動態
當管理員創建的靜態 PV 都不匹配用戶的 PersistentVolumeClaim 時，集羣可能會嘗試動態地爲 PVC 創建卷。此
配置基於 StorageClasses ：PVC 必須請求 [存儲類]，並且管理員必須創建並配置該類才能進行動態創建。聲明該
類爲 "" 可以有效地禁用其動態配置
要啓用基於存儲級別的動態存儲配置，集羣管理員需要啓用 API server 上的 DefaultStorageClass [准入控制器]
。例如，通過確保 DefaultStorageClass 位於 API server 組件的 --admission-control 標誌，使用逗號分隔的
有序值列表中，可以完成此操作1.5 綁定
master 中的控制環路監視新的 PVC，尋找匹配的 PV（如果可能），並將它們綁定在一起。如果爲新的 PVC 動態
調配 PV，則該環路將始終將該 PV 綁定到 PVC。否則，用戶總會得到他們所請求的存儲，但是容量可能超出要求
的數量。一旦 PV 和 PVC 綁定後， PersistentVolumeClaim 綁定是排他性的，不管它們是如何綁定的。 PVC 跟
PV 綁定是一對一的映射二 持久化卷聲明的保護
PVC 保護的目的是確保由 pod 正在使用的 PVC 不會從系統中移除，因爲如果被移除的話可能會導致數據丟失
當啓用PVC 保護 alpha 功能時，如果用戶刪除了一個 pod 正在使用的 PVC，則該 PVC 不會被立即刪除。PVC 的
刪除將被推遲，直到 PVC 不再被任何 pod 使用2.1 持久化卷類型
PersistentVolume 類型以插件形式實現。Kubernetes 目前支持以下插件類型：
GCEPersistentDisk AWSElasticBlockStore AzureFile AzureDisk FC (Fibre Channel)
FlexVolume Flocker NFS iSCSI RBD (Ceph Block Device) CephFS
Cinder (OpenStack block storage) Glusterfs VsphereVolume Quobyte Volumes
HostPath VMware Photon Portworx Volumes ScaleIO Volumes StorageOS2.2 持久卷演示代碼
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
storageClassName: slow
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /tmp
server: 172.17.0.22.3 PV 訪問模式
PersistentVolume 可以以資源提供者支持的任何方式掛載到主機上。如下表所示，供應商具有不同的功能，每個
PV 的訪問模式都將被設置爲該卷支持的特定模式。例如，NFS 可以支持多個讀/寫客戶端，但特定的 NFS PV 可能
以只讀方式導出到服務器上。每個 PV 都有一套自己的用來描述特定功能的訪問模式ReadWriteOnce——該卷可以被單個節點以讀/寫模式掛載
ReadOnlyMany——該卷可以被多個節點以只讀模式掛載
ReadWriteMany——該卷可以被多個節點以讀/寫模式掛載在命
在命令行中，訪問模式縮寫爲：
RWO - ReadWriteOnce
ROX - ReadOnlyMany
RWX - ReadWriteMany
2.4 回收策略
Retain（保留）——手動回收
Recycle（回收）——基本擦除（ rm -rf /thevolume/* ）
Delete（刪除）——關聯的存儲資產（例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷）
將被刪除
當前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持刪除策略2.5 狀態
卷可以處於以下的某種狀態：
Available（可用）——一塊空閒資源還沒有被任何聲明綁定
Bound（已綁定）——卷已經被聲明綁定
Released（已釋放）——聲明被刪除，但是資源還未被集羣重新聲明
Failed（失敗）——該卷的自動回收失敗
命令行會顯示綁定到 PV 的 PVC 的名稱2.6 持久化nfs 部署 配置
login node04.flyfish 配置nfs 服務
----
yum install -y nfs* nfs-utils rpcbind
mkdir /nfs
chmod 777 /nfs
chown nfsnobody /nfs
cat /etc/exports
/nfs *(rw,no_root_squash,no_all_squash,sync)
systemctl start rpcbind
systemctl start nfs
k8s 所有節點安裝nfs 客戶端的掛載包
login : node01.flyfish
yum install rpcbind nfs-utils
mkdir /test
showmount -e 192.168.100.14
mount -t nfs 192.168.100.14:/nfs /test
配置pv
vim pv.yaml
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs
server: 192.168.100.14
---
kubectl apply -f pv.yaml
kubectl get pv 
多創建幾個nfs pv
----
login: node04.flyfish
mkdir /nfs1 /nfs2 /nfs3
chmod 777 /nfs1 /nfs2 /nfs3
vim /etc/exportfs
---
/nfs *(rw,no_root_squash,no_all_squash,sync)
/nfs1 *(rw,no_root_squash,no_all_squash,sync)
/nfs2 *(rw,no_root_squash,no_all_squash,sync)
/nfs3 *(rw,no_root_squash,no_all_squash,sync)
---
service rpcbind restart
service nfs restart
exportfs -V
vim pv1.yaml
------
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv2
spec:
capacity:
storage: 20Gi
accessModes:
- ReadOnlyMany
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs1
server: 192.168.100.14
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv3
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: slow
nfs:
path: /nfs2
server: 192.168.100.14
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv4
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs3
server: 192.168.100.14
-----
kubectl apply -f pv1.yaml
kubectl get pv
創建PVC 應用
------
vim pvc.yaml
---
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: wangyanglinux/myapp:v1
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "nfs"
resources:
requests:
storage: 1Gi
---
kubectl apply -f pvc.yaml
---------
kubectl get pod
kubectl get pv
kubectl get pvc
以上可以看出 這個 pvc 的pod 並沒用創建 成功 要求的 副本數是3個 只創建了一個 pod， 因爲 如果要在 創建pod 必須滿足 accessModes: [ "ReadWriteOnce" ] 與 storageClassName: "nfs" 這兩個條件 ，但是 所創建的 pv 只有 nfsv1 同時滿足 這樣的條件 所以 就 只能創建 一個 pod
kubectl get pod
kubectl describe pod web-1
如果想 創建成功 必須給 改變pv的類型 與控制權限
首先刪掉nfspv3 與nfspv4
kubectl delete pv nfspv3
kubectl delete pv nfspv4
vim pv2.yaml
------
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv3
spec:
capacity:
storage: 30Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs2
server: 192.168.100.14
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv4
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs3
server: 192.168.100.14
------
kubectl apply -f pv2.yaml
kubectl get pv
kubectl get pod 
kubectl get pv
kubectl get pvc 
kubectl describe pv nfspv1
kubectl describe pv nfspv2
kubectl descirbe pv nfspv3
kubectl descirbe pv nfspv4
kubectl get pv
kubectl get pod -o wide
login node04.flyfish
cd /nfs
echo aaaaa > index.html
cd /nfs2
echo bbbb >> index.html
cd /nfs3
echo "web2 web2" >> index.html
curl 10.244.1.6
curl 10.244.2.8
curl 10.244.2.7
kubectl delete pod web-0
三 關於 StatefulSet
3.1 StatfulSet的理解
3.1匹配 Pod name ( 網絡標識 ) 的模式爲：$(statefulset名稱)-$(序號)，比如上面的示例：web-0，web-1，
web-2
3.2 StatefulSet 爲每個 Pod 副本創建了一個 DNS 域名，這個域名的格式爲： $(podname).(headless server
name)，也就意味着服務間是通過Pod域名來通信而非 Pod IP，因爲當Pod所在Node發生故障時， Pod 會
被飄移到其它 Node 上，Pod IP 會發生變化，但是 Pod 域名不會有變化
3.3 StatefulSet 使用 Headless 服務來控制 Pod 的域名，這個域名的 FQDN 爲：$(service
name).$(namespace).svc.cluster.local，其中，“cluster.local” 指的是集羣的域名
3.4 根據 volumeClaimTemplates，爲每個 Pod 創建一個 pvc，pvc 的命名規則匹配模式：
(volumeClaimTemplates.name)-(pod_name)，比如上面的 volumeMounts.name=www， Pod
name=web-[0-2]，因此創建出來的 PVC 是 www-web-0、www-web-1、www-web-2
3.5刪除 Pod 不會刪除其 pvc，手動刪除 pvc 將自動釋放 pv
3.2 statfulset
有序部署：部署StatefulSet時，如果有多個Pod副本，它們會被順序地創建（從0到N-1）並且，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態。
有序刪除：當Pod被刪除時，它們被終止的順序是從N-1到0。
有序擴展：當對Pod執行擴展操作時，與部署一樣，它前面的Pod必須都處於Running和Ready狀態。有序刪除：
3.3 StatefulSet使用場景：
1.穩定的持久化存儲，即Pod重新調度後還是能訪問到相同的持久化數據，基於 PVC 來實現。
2.穩定的網絡標識符，即 Pod 重新調度後其 PodName 和 HostName 不變。
有序部署，有序擴展，基於 init containers 來實現。
3.有序收縮。
3.4 statefulset 整體刪除步驟
先刪除 pod
kubectl delete pod --all
在刪除svc
kubectl delete svc --all
在刪除deployment
kubectl delete deploy --all
在刪除statefulset
kubectl delete statefulset --all
在刪除 pvc
kubectl delete pvc --all
刪除 pv
kubectl delete pv --all
然後 在刪掉 nfs掛載裏面的文件
