參考文章 https://www.cnblogs.com/benjamin77/p/9944268.html
pv = PersistentVolume 存儲的定義,生命周期獨立于pod,是一塊建立好的持久化空間,由管理者管理, 應用無需關心,隻需要提出申請使用即可
pvc = PersistentVolumeClaim 存儲的聲明
經過個人的了解 pv跟pvc是一一對應關系, pv 被使用了後就不能被其它pvc申請了, 看過很多文章說, 隻要管理者建立好pv, 開發人員隻要寫pvc申請就行了, 手工維護的不太可能, 還是要動态生成 pv , 一一對應關系有什麼好處?
一直沒明白網上說的好處, 減少耦合,這還不是一一對應關系嘛,緊密結合呀,用完了還是清掉讓後面的人用, 也許唯一的好處就是清掉後不要再重新建立新的了, 這對大規模的使用也許有好處吧.
使用我們已經定義好的nfs 參考 https://mp.csdn.net/postedit/93199622
下面開始建立 pv
vi pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: mypv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
nfs:
path: /home/nfs
server: 192.168.220.128
開始建立
kubectl apply -f pv.yaml
檢視狀态
kubectl get pv
pvc
打開mysql的helm定義的pvc.yaml做為例子來分析一下
{{- if and .Values.persistence.enabled (not .Values.persistence.existingClaim) }}
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: {{ template "mysql.fullname" . }}
namespace: {{ .Release.Namespace }}
{{- with .Values.persistence.annotations }}
annotations:
{{ toYaml . | indent 4 }}
{{- end }}
labels:
app: {{ template "mysql.fullname" . }}
chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
release: "{{ .Release.Name }}"
heritage: "{{ .Release.Service }}"
spec:
accessModes:
- {{ .Values.persistence.accessMode | quote }}
resources:
requests:
storage: {{ .Values.persistence.size | quote }}
{{- if .Values.persistence.storageClass }}
{{- if (eq "-" .Values.persistence.storageClass) }}
storageClassName: ""
{{- else }}
storageClassName: "{{ .Values.persistence.storageClass }}"
{{- end }}
{{- end }}
{{- end }}
PVC ,隻需要指定 PV 的容量,通路模式和 class。
這裡面 .Values.persistence.size 指容量 1Gi 這樣的寫法
通路模式 .Values.persistence.accessMode =
ReadWriteOnce
accessModes
指定通路模式為
ReadWriteOnce
,支援的通路模式有:
ReadWriteOnce – PV 能以 read-write 模式 mount 到單個節點。 不太了解單個跟多個節點是什麼概念?
ReadOnlyMany – PV 能以 read-only 模式 mount 到多個節點。
ReadWriteMany – PV 能以 read-write 模式 mount 到多個節點。
class .Values.persistence.storageClass = nfs