k 8 sノート(7)--ストレージボリューム
12342 ワード
ストレージボリューム
k 8 sストレージボリューム(Volume)はdockerストレージボリュームと同様に、データの永続的なストレージまたはデータ共有を提供するために使用されます.ただしdockerストレージボリュームはコンテナにマウントされ、コンテナのライフサイクルを伴うことができ、k 8 sストレージボリュームはpodにマウントされ、podのライフサイクルを伴うことができるため、pod中のコンテナの再起動はボリュームに影響しないが、podが再構築されるとボリュームに影響を与える可能性がある.
ストレージボリュームタイプ
k 8 sは多くのボリュームをサポートしています.ここでは、emptyDir、hostpath、nfs、pvc、pv、configmap、secretという簡単なストレージボリュームについて説明します.分散型ストレージボリュームまたはクラウドストレージについては説明しません.
#
kubectl explain pod.spec.volumes
#
kubectl explain pod.spec.containers.volumeMounts
ボリューム使用上の注意:
emptyDir
Podがノードに割り当てられると、emptyDirが作成され、ノードに対応する空のディレクトリが自動的に割り当てられます.ノード上のPodがずっと実行されている限り、emptyDirはずっと存在します.本明細書では、emptyDirのみがPodライフサイクルを伴い、Podがノードから削除されると、emptyDirも同時に削除され、格納されたデータも永続的に削除されます.注意:Podのコンテナを削除してもemptyDirには影響しません.
emptyNode使用シーン:
1)プログラム一時ディレクトリ
2)memory:メモリファイルシステム(tmps)でシステムにマウントする場合、nodeが再起動するとemptyDirは自動的に空になります.同時にemptyDirに書き込むファイルは、Containerのメモリ使用制限に計上されます.
# cat emptyDir-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: emptydir-demo
namespace: default
labels:
demo: emptydir
spec:
containers:
- name: nginx
image: nginx:1.17.5-alpine
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html/
- name: busybox
image: busybox:latest
imagePullPolicy: IfNotPresent
command:
- "/bin/sh"
- "-c"
- "while true; do date >> /www/index.html ;sleep 10;done"
volumeMounts:
- name: html
mountPath: /www
volumes:
- name: html
emptyDir: {}
アクセステストを作成すると、emptydirが共有されていることがわかります.
# curl 10.244.1.62
Thu Dec 05 04:16:03 UTC 2019
# kubectl exec -it emptydir-demo -c nginx cat /usr/share/nginx/html/index.html
Thu Dec 05 04:16:03 UTC 2019
Thu Dec 05 04:16:13 UTC 2019
Thu Dec 05 04:16:23 UTC 2019
# kubectl exec -it emptydir-demo -c busybox cat /www/index.html
Thu Dec 05 04:16:03 UTC 2019
Thu Dec 05 04:16:13 UTC 2019
Thu Dec 05 04:16:23 UTC 2019
削除再構築pod見てemptydirも削除再構築されました
# kubectl replace -f emptyDir-demo.yaml --force
# curl 10.244.1.63
Thu Dec 05 04:24:56 UTC 2019
# kubectl exec -it emptydir-demo -c busybox tail /www/index.html
Thu Dec 05 04:24:56 UTC 2019
Thu Dec 05 04:25:06 UTC 2019
hostPath
emptyDirと同様に、hostpathは、ローカルnodeがすでに存在する
またはディレクトリをpodにマウントし、podサイクルに伴って永続化されたストレージまたは共有を実現することができる.ただしpodがホスト間で再構築されると、コンテナhostPathファイルの内容が変更される可能性があります.したがってhostPathは、通常、このノードコンテナログ収集のようにDaemonSetと組み合わせて使用されます.Directory OrCreate:指定したパスに何もない場合は、必要に応じて空のディレクトリを作成し、権限を0755に設定します.このディレクトリはKubeletと同じグループと所有権を持っています.つまり、プロセスはroot権限でディレクトリに書き込むか、手動でマウントディレクトリ権限を変更する必要があります.
kubectl explain pod.spec.volumes.hostPath # UTC， hostPath
# cat hostPath-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-hostpath-demo
namespace: default
labels:
app: mynginx
tier: frontend
annotations:
bubble/createby: "cluster admin"
spec:
containers:
- name: nginx
image: nginx:1.17.5-alpine
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
volumeMounts:
- name: html
mountPath: /var/log/nginx
- name: localtime
mountPath: /etc/localtime
volumes:
- name: html
hostPath:
path: /data/pod/hostPath
type: DirectoryOrCreate
- name: localtime
hostPath:
path: /etc/localtime
type: File
アクセステストではpod再構築後hostpathの内容が変わっていないことがわかります
# kubectl exec -it pod-hostpath-demo tail /var/log/nginx/access.log
10.244.0.0 - - [05/Dec/2019:16:57:00 +0800] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.29.0" "-"
# kubectl replace -f pod-hostpath-demo.yaml --force
pod "pod-hostpath-demo" deleted
pod/pod-hostpath-demo replaced
# kubectl exec -it pod-hostpath-demo tail /var/log/nginx/access.log
10.244.0.0 - - [05/Dec/2019:16:57:00 +0800] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.29.0" "-"
nfs
nfsはネットワークストレージであり,直接ストレージボリュームとして使用できpod間のデータ共有を実現する.podが削除されるとnfsのみが自動的にアンインストールされ、nfsの内容は保持されます.
# cat nfs-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: nfs-demo
namespace: default
labels:
app: nfs
spec:
containers:
- name: nginx
image: nginx:1.17.5-alpine
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html/
volumes:
- name: html
nfs:
path: /data/pod/nfs
server: node2.xlbubble.xyz
アクセステスト
# curl 10.244.1.66
nfs on node2.xlbubble.xyz
# pod ： node nfs
PVとPVC
pv(PersistentVolum)は、物理ストレージに基づくクラスタ内のストレージリソースである.そのライフサイクルはpodとは関係ありません.
pvc(PersistentVolumClaim)は、pv抽象に基づく記憶要求である.PodはPVCにより物理記憶を要求する.
pvボリュームプラグインがサポートする物理ストレージ(Kubernetes v 1.13+):ローカルストレージ、iscsi、クラウドハードディスク、Vsphereストレージなど、具体的には公式サイトを参照してください.
pvの作成
まずnfsタイプの永続化ストレージボリュームを作成し、pvcにストレージボリュームを提供します.
# node2.xlbubble.xyz nfs
[root@node2 ~]# exportfs -arv
exporting *:/data/pod/v4
exporting *:/data/pod/v3
exporting *:/data/pod/v2
exporting *:/data/pod/v1
exporting *:/data/pod/nfs
複数のpvを作成し、ボリュームサイズやIO方式、IO性能など、さまざまな機能を提供できます.
# cat pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001
labels:
name: pv001
spec:
nfs: # nfs
path: /data/pod/pv1 # nfs
server: node2.xlbubble.xyz # nfs server
accessModes: ["ReadWriteOnce"] #
capacity: # pv
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv002
labels:
name: pv002
spec:
nfs:
path: /data/pod/pv2
server: node2.xlbubble.xyz
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 5Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv003
labels:
name: pv003
spec:
nfs:
path: /data/pod/pv3
server: node2.xlbubble.xyz
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 10Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv004
labels:
name: pv004
spec:
nfs:
path: /data/pod/pv4
server: node2.xlbubble.xyz
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 20Gi
# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv001 2Gi RWO Retain Available 33s
pv002 5Gi RWO,RWX Retain Available 33s
pv003 10Gi RWO,RWX Retain Available 33s
pv004 20Gi RWO,RWX Retain Available 33s
pvcを作成しpodを作成しpvcを指定
# cat pvc-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mypvc
namespace: default
spec:
accessModes: ["ReadWriteMany"]
resources:
requests:
storage: 4Gi # 4G pvc
# cat pvc-pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: pvc-demo
namespace: default
labels:
app: mynginx
tier: frontend
annotations:
bubble/createby: "cluster admin"
spec:
containers:
- name: nginx
image: nginx:alpine
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html/
volumes:
- name: html
persistentVolumeClaim:
claimName: mypvc
現在、pvcはpv 002号ストレージボリュームをバインドしています.ここでは、要求に合致する静的pvを自動的に探してバインドします.要求に合致するpvがなければ、pvcは要求に合致するpvが作成されるまでpending状態になります.
静的pv:上記のように.
動的pv:要求に合致するpvがない場合、複数のpvが1つにバンドルされ、ストレージが提供されます.pvクラスタがまだ要求に合致していない場合、pvcはpvクラスタが要求に合致するまでpendingを継続する.動的pvはStorageClassesに基づいており、StorageClassesをサポートするボリュームプラグインが必要です.
# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mypvc Bound pv002 5Gi RWO,RWX 11s
# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv001 2Gi RWO Retain Available 22s
pv002 5Gi RWO,RWX Retain Bound default/mypvc 22s
pv003 10Gi RWO,RWX Retain Available 22s
pv004 20Gi RWO,RWX Retain Available 22s
アクセステスト
# curl 10.244.2.72
pv2 on node2.xlbubble.xyz
注意!今回試験したIOモード:nfs(rw)-->pv(rw)-->pvc(rw).構成中に、構成ごとにストレージ権限が要求に合致していることを確認します.
ボリュームの削除
使用中のストレージオブジェクト保護メカニズム
pvcを削除する前にk 8 sはpvcにバインドpodがあるかどうかを確認し、バインドがあればすぐに削除せず、pod側が自発的にバインドを解除するのを待っています.同様に、pvを削除する前にバインドpvcがあるかどうかを確認し、バインドがあればすぐに削除せず、pvc側が自発的にバインドを解除するのを待っています.
Finalizers: [kubernetes.io/pvc-protection] # kubectl describe pvc mypvc
Name: mypvc
Namespace: default
StorageClass:
Status: Bound
Volume: pv003
Labels:
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"name":"mypvc","namespace":"default"},"spec":{"accessModes"...
pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
Finalizers: [kubernetes.io/pvc-protection]
削除後の回収ポリシー
回収ポリシーには、保存、削除、回収(廃棄)が含まれます.
静的pvのデフォルトでは、pvcまたはpvを削除すると、データは元の物理ストレージに保存されます.データが不要であることを確認すると、手動でクリーンアップできます.
pvcを削除した後もpvはReleased状態であり、pvはpvc宣言のdefault/mypvc(pvcとpvの1対1マッピング)であり、pvcを再バインドすることはできません.再構築pvを手動で削除したり、pv宣言を変更したりすることができます.
kubectl delete -f pvc-demo.yaml
# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv001 2Gi RWO Retain Available 93m
pv002 5Gi RWO,RWX Retain Released default/mypvc 93m
pv003 10Gi RWO,RWX Retain Available 93m
pv004 20Gi RWO,RWX Retain Available 93m
# kubectl edit pv
...
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: mypvc
namespace: default
resourceVersion: "3498958"
uid: 2a110677-d6d6-495e-8b95-5f7cbb49e104
...
動的pvのデフォルトでは、削除ポリシーが使用されます.pvcまたはpvを削除すると、元の物理記憶上のデータも削除されます.
公式は
kubectl patch pv YOURPVNAME -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'を通じてpvの回収戦略を修正することを提案している.configmapとsecret
To Be Continued
リファレンスと拡張
k8s-storage