目錄
所有的中間層都是為了解耦
中間件（英語：Middleware），又譯中間件、中介層，是提供系統軟件和應用軟件之間連接的軟件，以便於軟件各部件之間的溝通。在現代信息技術應用框架如 Web 服務、面向服務的體系結構等項目中應用比較廣泛。如數據庫、Apache 的 Tomcat ，IBM 公司的 WebSphere ,BEA 公司的 WebLogic 應用服務器，東方通公司的 Tong 系列中間件，以及 Kingdee 公司的等都屬於中間件。
PV，PVC簡介
1.1 介紹
管理存儲是管理計算的一個明顯問題。該PersistentVolume子系統為用戶和管理員提供了一個API，用於抽象如何根據消費方式提供存儲的詳細信息。為此，我們引入了兩個新的
API資源：PersistentVolume和PersistentVolumeClaim
PersistentVolume（
PV）是集群中由管理員配置的一段網絡存儲。 它是集群中的資源，就像節點是集群資源一樣。 PV是容量插件，如Volumes，但其生命周期獨立於使用PV的任何單個pod。 此API對象捕獲存儲實現的詳細信息，包括NFS，iSCSI或特定於雲提供程序的存儲系統。
PersistentVolumeClaim（
PVC）是由用戶進行存儲的請求。 它類似於pod。 Pod消耗節點資源，PVC消耗PV資源。Pod可以請求特定級別的資源（CPU和內存）。聲明可以請求特定的大小和訪問模式（例如，可以一次讀/寫或多次只讀）。
雖然PersistentVolumeClaims允許用戶使用抽象存儲資源，但是PersistentVolumes對於不同的問題，用戶通常需要具有不同屬性（例如性能）。群集管理員需要能夠提供各種PersistentVolumes不同的方式，而不僅僅是大小和訪問模式，而不會讓用戶了解這些卷的實現方式。對於這些需求，有
StorageClass 資源。
StorageClass為管理員提供了一種描述他們提供的存儲的“類”的方法。 不同的類可能映射到服務質量級別，或備份策略，或者由群集管理員確定的任意策略。 Kubernetes本身對於什么類別代表是不言而喻的。 這個概念有時在其他存儲系統中稱為“配置文件”。
PVC和PV是一一對應的。
1.2 生命周期
PV是群集中的資源。PVC是對這些資源的請求，並且還充當對資源的檢查。PV和PVC之間的相互作用遵循以下生命周期：
Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling
- 供應准備Provisioning---通過集群外的存儲系統或者雲平台來提供存儲持久化支持。
- - 靜態提供Static：集群管理員創建多個PV。 它們攜帶可供集群用戶使用的真實存儲的詳細信息。 它們存在於Kubernetes API中，可用於消費
- - 動態提供Dynamic：當管理員創建的靜態PV都不匹配用戶的PersistentVolumeClaim時，集群可能會嘗試為PVC動態配置卷。 此配置基於StorageClasses：PVC必須請求一個類，並且管理員必須已創建並配置該類才能進行動態配置。 要求該類的聲明有效地為自己禁用動態配置。
- 綁定Binding---用戶創建pvc並指定需要的資源和訪問模式。在找到可用pv之前，pvc會保持未綁定狀態。
- 使用Using---用戶可在pod中像volume一樣使用pvc。
- 釋放Releasing---用戶刪除pvc來回收存儲資源，pv將變成“released”狀態。由於還保留着之前的數據，這些數據需要根據不同的策略來處理，否則這些存儲資源無法被其他pvc使用。
- 回收Recycling---pv可以設置三種回收策略：保留（Retain），回收（Recycle）和刪除（Delete）。
- - 保留策略：允許人工處理保留的數據。
- - 刪除策略：將刪除pv和外部關聯的存儲資源，需要插件支持。
- - 回收策略：將執行清除操作，之后可以被新的pvc使用，需要插件支持。
注：目前只有NFS和HostPath類型卷支持回收策略，AWS EBS,GCE PD,Azure Disk和Cinder支持刪除(Delete)策略。
掛載磁盤分兩步：
Attach，為虛擬機掛載遠程磁盤的操作。kubelet 為 Volume 創建目錄，並綁定遠程存儲。
Mount，磁盤設備格式化並掛載到 Volume 宿主機目錄的操作
如果你的 Volume 類型是遠程文件存儲（比如 NFS）的話，kubelet跳過“第一階段”（Attach）的操作
1.4 PV卷階段狀態
- Available – 資源尚未被claim使用
- Bound – 卷已經被綁定到claim了
- Released – claim被刪除，卷處於釋放狀態，但未被集群回收。
- Failed – 卷自動回收失敗
靜態PV，PVC創建和使用
1. 創建pv存儲，實際的存儲資源
[root@m3 test]# vim pv-nfs.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-nfs
spec:
storageClassName: nfs1
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
nfs:
server: 192.168.70.94
path: "/data/nfs/v1"
[root@m3 test]# kubectl apply -f pv-nfs.yaml
persistentvolume/pv-nfs created
[root@m3 test]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-nfs 1Gi RWX Retain Available nfs1 41s
2. PVC 描述的，則是 Pod 所希望使用的持久化存儲的屬性。
[root@m3 test]# vim pvc-nfs.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-nfs
namespace: default
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 100M
storageClassName: nfs1
[root@m3 test]# kubectl apply -f pvc-nfs.yaml
persistentvolumeclaim/pvc-nfs created
Volume Controller：專門處理持久化存儲的控制器
PersistentVolumeController ：處理pv和pvc
PersistentVolumeController 會不斷地查看當前每一個 PVC，是不是已經處於 Bound（已綁定）狀態。如果不是，那它就會遍歷所有的、可用的 PV，並嘗試將其與這個“單身”的 PVC 進行綁定。這樣，Kubernetes 就可以保證用戶提交的每一個 PVC，只要有合適的 PV 出現，它就能夠很快進入綁定狀態
PVC和PV綁定條件：
- storageClassName 字段一致
- PV 滿足 PVC 的 spec 字段
[root@m3 test]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc-nfs Bound pvc-nfs 1Gi RWX nfs1 2m34s
[root@m3 test]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-nfs 1Gi RWX Retain Bound default/pvc-nfs nfs1 6m26s
3.pvc資源的使用
[root@m3 test]# vim pvc-nfs-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: pvc-nfs-pod
spec:
containers:
- name: web
image: nginx:1.7.9
volumeMounts:
storageClassName- name: nfs
mountPath: "/usr/share/nginx/html"
volumes:
- name: nfs
persistentVolumeClaim:
claimName: nfs1
[root@m3 test]# kubectl apply -f pvc-nfs-pod.yaml
pod/pvc-nfs-pod created
訪問nginx進行驗證
[root@m3 test]# kubectl get pod -o wide | grep pvc-nfs-pod
pvc-nfs-pod 1/1 Running 0 3m13s 10.100.130.101 s3 <none> <none>
[root@m3 test]# curl http://10.100.130.101
hello nfs
動態持久化存儲StorageClass
我們學習了 PV 和 PVC 的使用方法，但是前面的 PV 都是靜態的，什么意思？就是我要使用的一個 PVC 的話就必須手動去創建一個 PV，我們也說過這種方式在很大程度上並不能滿足我們的需求，比如我們有一個應用需要對存儲的並發度要求比較高，而另外一個應用對讀寫速度又要求比較高，特別是對於 StatefulSet 類型的應用簡單的來使用靜態的 PV 就很不合適了，這種情況下我們就需要用到動態 PV，也就是我們今天要講解的 StorageClass。
而 StorageClass 對象的作用，其實就是創建 PV 的模板。具體地說，StorageClass 對象會定義如下兩個部分內容：
第一，PV 的屬性。比如，存儲類型、Volume 的大小等等。
第二，創建這種 PV 需要用到的存儲插件。比如，Ceph 等等。
nfs創建pv並自動綁定pvc
1.創建ServiceAccount賬號
創建賬號
，nfs-client-provisioner服務啟動時需要以此賬號的權限啟動和運行
[root@m3 nfs]# cat nfs-client-provisioner.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: eip-nfs-client-provisioner
namespace: kube-system
[root@m3 nfs]# kubectl apply -f nfs-client-provisioner.yaml
serviceaccount/nfs-client-provisioner created
2.創建集群role角色
[root@m3 nfs]# cat nfs-client-provisioner-runner.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: nfs-client-provisioner-runner
namespace: kube-system
rules:
- apiGroups:
- ''
resources:
- persistentvolumes
verbs:
- get
- list
- watch
- create
- delete
- apiGroups:
- ''
resources:
- persistentvolumeclaims
verbs: [ get, list, watch, update ]
- apiGroups:
- storage.k8s.io
resources:
- storageclasses
verbs: [ get, list, watch ]
- apiGroups:
- ''
resources:
- events
verbs: [ create, update, patch ]
[root@m3 nfs]# kubectl apply -f nfs-client-provisioner-runner.yaml
clusterrole.rbac.authorization.k8s.io/nfs-client-provisioner-runner created
3.使role角色和ServiceAccount賬號綁定
[root@m3 nfs]# cat run-nfs-client-provisioner.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: run-nfs-client-provisioner
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: nfs-client-provisioner-runner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: kube-system
[root@m3 nfs]# kubectl apply -f run-nfs-client-provisioner.yaml
clusterrolebinding.rbac.authorization.k8s.io/run-nfs-client-provisioner created
4.創建role角色，賦予權限
[root@m3 ~]# cat leader-locking-nfs-client-provisioner.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: leader-locking-nfs-client-provisioner
namespace: kube-system
rules:
- apiGroups:
- ''
resources:
- endpoints
verbs:
- get
- list
- watch
- create
- update
- patch
[root@m3 ~]# kubectl apply -f leader-locking-nfs-client-provisioner.yaml
role.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
5. 將role角色和ServiceAccount綁定
[root@m3 ~]# cat leader-locking-nfs-client-provisioner-bind.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: leader-locking-nfs-client-provisioner
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: leader-locking-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: kube-system
[root@m3 ~]# kubectl apply -f leader-locking-nfs-client-provisioner-bind.yaml
rolebinding.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
6.創建nfs 工作端
[root@m3 ~]# vim nfs-nfs3.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nfs-nfs3
name: nfs-nfs3
namespace: kube-system
spec:
replicas: 1
selector:
matchLabels:
app: nfs-nfs3
strategy:
type: Recreate
template:
metadata:
labels:
app: nfs-nfs3
spec:
containers:
- env:
- name: PROVISIONER_NAME
value: nfs-nfs3
- name: NFS_SERVER
value: 192.168.70.120
- name: NFS_PATH
value: /data/nfs/v3
image: 'quay.io/external_storage/nfs-client-provisioner:v3.1.0-k8s1.11'
name: nfs-client-provisioner
volumeMounts:
- mountPath: /persistentvolumes
name: nfs-client-root
serviceAccountName: eip-nfs-client-provisioner
volumes:
- name: nfs-client-root
nfs:
path: /data/nfs/v3
server: 192.168.70.120
[root@m3 ~]# kubectl apply -f nfs-nfs3.yaml
deployment.apps/nfs-nfs3 created
7. 創建nfs StorageClass
[root@m3 nfs]# vim nfs-StorageClass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
k8s.eip.work/storageType: nfs_client_provisioner
name: nfs3
parameters:
archiveOnDelete: 'false'
provisioner: nfs-nfs3
reclaimPolicy: Delete
volumeBindingMode: Immediate
[root@m3 nfs]# kubectl apply -f nfs-StorageClass.yaml
storageclass.storage.k8s.io/nfs3 created
[root@m3 nfs]# kubectl get pod -n kube-system | grep nfs3
nfs-nfs3-66f4c9bcd5-5fd2x 1/1 Running 0 3m21s
reclaimPolicy回收策略: Delete立刻刪除 Retain pvc刪除后保留磁盤
volumeBindingMode綁定策略: Immediate立即綁定，WaitForFirstConsumer第一次使用時綁定
8.進行nfs測試
[root@m3 nfs]# cat nfs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-nfs
namespace: default
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 2M
storageClassName: nfs3
[root@m3 nfs]# kubectl apply -f nfs-pvc.yaml
persistentvolumeclaim/pvc-nfs created
[root@m3 ~]# kubectl get pvc | grep pvc-nfs
pvc-nfs Bound pvc-4773b235-aa7c-4c8e-bf81-85c97e0e28f6 2M RWX nfs3 78s
[root@m3 ~]# kubectl get pv | grep pvc-nfs
pvc-4773b235-aa7c-4c8e-bf81-85c97e0e28f6 2M RWX Delete Bound default/pvc-nfs nfs3 88s