Kubernetes-ストレージボリュームVolume
6559 ワード
1、ストレージボリュームの概要
コンテナ自体が非永続化されているため、コンテナ内でアプリケーションを実行する際に発生する問題を解決する必要があります.まず、コンテナがクラッシュするとkubeletはコンテナを再起動しますが、コンテナに書き込まれたファイルは失われ、コンテナはミラーの初期状態で再開始されます.第二に、1つのPodで一緒に実行されるコンテナでは、通常、コンテナ間のファイルを共有する必要があります.Kubernetesは、上記の2つの問題をストレージボリュームで解決します.
Dockerにはストレージボリュームのコンセプトボリュームがありますが、Dockerにはストレージボリュームがディスクまたは別のコンテナのディレクトリにすぎず、ライフサイクルを管理していません.Kubernetesのストレージボリュームには独自のライフサイクルがあり、そのライフサイクルは使用するPodライフサイクルと一致しています.したがって、ストレージボリュームは、Podで実行されているコンテナに比べて、どのコンテナよりも長く存在し、コンテナの再起動時にデータが保持されます.もちろん、Podが存在しなくなると、ストレージボリュームも存在しなくなります.Kubernetesでは複数のタイプのボリュームがサポートされていますが、Podではさまざまなタイプと任意の数のストレージボリュームを同時に使用できます.Podでは、次のフィールドを指定してストレージボリュームを使用します.
spec.volumes:指定されたストレージボリュームをこのフィールドで提供します.
spec.containers.volumeMounts:このフィールドを使用して、ストレージボリュームをコンテナのに接続します.
2、ストレージボリュームの種類と例
コンテナ自体が非永続化されているため、コンテナ内でアプリケーションを実行する際に発生する問題を解決する必要があります.まず、コンテナがクラッシュするとkubeletはコンテナを再起動しますが、コンテナに書き込まれたファイルは失われ、コンテナはミラーの初期状態で再開始されます.第二に、1つのPodで一緒に実行されるコンテナでは、通常、コンテナ間のファイルを共有する必要があります.Kubernetesは、上記の2つの問題をストレージボリュームで解決します.
Dockerにはストレージボリュームのコンセプトボリュームがありますが、Dockerにはストレージボリュームがディスクまたは別のコンテナのディレクトリにすぎず、ライフサイクルを管理していません.Kubernetesのストレージボリュームには独自のライフサイクルがあり、そのライフサイクルは使用するPodライフサイクルと一致しています.したがって、ストレージボリュームは、Podで実行されているコンテナに比べて、どのコンテナよりも長く存在し、コンテナの再起動時にデータが保持されます.もちろん、Podが存在しなくなると、ストレージボリュームも存在しなくなります.Kubernetesでは複数のタイプのボリュームがサポートされていますが、Podではさまざまなタイプと任意の数のストレージボリュームを同時に使用できます.Podでは、次のフィールドを指定してストレージボリュームを使用します.
spec.volumes:指定されたストレージボリュームをこのフィールドで提供します.
spec.containers.volumeMounts:このフィールドを使用して、ストレージボリュームをコンテナのに接続します.
2、ストレージボリュームの種類と例
現在のKubernetesでは、以下のようなストレージボリュームタイプがサポートされており、hostPath、nfs、p e r sistentVolumeClaimタイプのストレージボリュームを例に、ストレージボリュームの定義方法、Podでの使用方法について説明します.
awsElasticBlockStore
azureDisk
azureFile
cephfs
configMap
csi
downwardAPI
emptyDir
fc (fibre channel)
flocker
gcePersistentDisk
gitRepo
glusterfs
hostPath
iscsi
local
nfs
persistentVolumeClaim
projected
portworxVolume
quobyte
rbd
scaleIO
secret
storageos
vsphereVolume
2.1 hostPath
hostPathタイプのストレージボリュームは、ホストのファイルシステムのファイルまたはディレクトリをPodにマウントするために使用され、pathフィールドを指定する必要があるほか、hostPathタイプのストレージボリュームを使用する場合にtypeを設定することもでき、typeがサポートする列挙値は以下の表に示す.またhostPathを使用する場合は、次の点に注意してください.
同じ構成のPod(たとえば、同じpodTemplateから作成されたもの)は、Nodeのファイルによって動作が異なる場合があります.
ホスト上に作成されたファイルまたはディレクトリは、rootユーザーのみが書き込む権限を持っています.コンテナでrootとしてプロセスを実行するか、ホスト上でhostPathのストレージボリュームにコンテンツを書き込むためにファイルまたはディレクトリを変更する権限があります.
値
動作
空の文字列(デフォルト)は後方互換性に使用されます.これは、ホストパスストレージボリュームをマウントする前にチェックが行われないことを意味します.DirectoryOrCreate
pathがディレクトリが存在しないことを指定すると、シンクホストに新しいディレクトリが作成され、kubeletと同じグループと所有者を持つディレクトリ権限0755が設定されます.Directory
path指定のターゲットは必須ですFileOrCreate
pathが指定したファイルが存在しない場合、シンクホストに空のファイルが作成され、権限が0644に設定されます.このファイルはkubeletと同じグループと所有者を持っています.File
path指定ファイルは必須ですSocket
Path指定UNIXソケットは必須ですCharDevice
path指定の文字デバイスは必須ですBlockDevice
pathの所与の経路にブロックデバイスが存在する必要がある.
次に、test-pdという名前のPodリソースを定義するhostPathをストレージボリュームとして使用するYAMLファイルを示します.hostPathタイプのストレージボリュームを使用して、Podホスト上の/dataをコンテナ内の/teset-pdディレクトリにマウントします.apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
#
volumeMounts:
- mountPath: /test-pd
name: test-volume
#
volumes:
- name: test-volume
hostPath:
#
path: /data
# this field is optional
type: Directory
2.2 NFS
Kubernetesでは、既存のNFS(ネットワークファイルシステム)からPodにnfsタイプのストレージボリュームを介して一時停止することができる.Podを削除すると、NFSストレージボリュームの内容は削除されず、ストレージボリュームをアンインストールするだけです.これは、NFSストレージボリューム全体においてデータを予め埋め込み、Pod間でデータを共有できることを意味する.NFSは複数のPodに同時に引っ掛かることができ,同時に書き込むことができる.nfsストレージボリュームを使用する前に、NFSサーバが正しく配備され、実行され、共有ディレクトリが設定されていることに注意してください.
次はredisが配置したYAMLプロファイルで、redisはコンテナ内の永続化データを/dataディレクトリの下に保存します.ストレージボリュームはnfsを使用し、nfsのサービスアドレスは192.168.8.150、ストレージパスは/k 8 s-nfs/redis/dataです.容器はvolumeMountsを通過する.nameの値は、使用するストレージボリュームを決定します.apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: redis
spec:
selector:
matchLabels:
app: redis
revisionHistoryLimit: 2
template:
metadata:
labels:
app: redis
spec:
containers:
#
- image: redis
name: redis
imagePullPolicy: IfNotPresent
#
ports:
- containerPort: 6379
name: redis6379
env:
- name: ALLOW_EMPTY_PASSWORD
value: "yes"
- name: REDIS_PASSWORD
value: "redis"
# ， docker
volumeMounts:
- name: redis-persistent-storage
mountPath: /data
volumes:
#
- name: redis-persistent-storage
nfs:
path: /k8s-nfs/redis/data
server: 192.168.8.150
2.3 persistentVolumeClaim
persistentVolumeClaimタイプのストレージボリュームは、PersistentVolumeをPodにマウントしてストレージボリュームとして使用します.このタイプのストレージボリュームを使用すると、ユーザーはストレージボリュームの詳細を知りません.
ここではbusybox-deploymentという名前の配置YAMLプロファイルを定義し、使用するミラーはbusyboxです.busyboxミラーベースのコンテナは/mntディレクトリのデータを永続化する必要があり、YAMLファイルではnfsという名前のPersistenVolumeClaimを使用してコンテナのデータを永続化することを指定します.# This mounts the nfs volume claim into /mnt and continuously
# overwrites /mnt/index.html with the time and hostname of the pod.
apiVersion: v1
kind: Deployment
metadata:
name: busybox-deployment
spec:
replicas: 2
selector:
name: busybox-deployment
template:
metadata:
labels:
name: busybox-deployment
spec:
containers:
- image: busybox
command:
- sh
- -c
- 'while true; do date > /mnt/index.html; hostname >> /mnt/index.html; sleep $(($RANDOM % 5 + 5)); done'
imagePullPolicy: IfNotPresent
name: busybox
volumeMounts:
# name must match the volume name below
- name: nfs
mountPath: "/mnt"
volumes:
- name: nfs
persistentVolumeClaim:
claimName: nfs-pvc
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
#
volumeMounts:
- mountPath: /test-pd
name: test-volume
#
volumes:
- name: test-volume
hostPath:
#
path: /data
# this field is optional
type: DirectoryapiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: redis
spec:
selector:
matchLabels:
app: redis
revisionHistoryLimit: 2
template:
metadata:
labels:
app: redis
spec:
containers:
#
- image: redis
name: redis
imagePullPolicy: IfNotPresent
#
ports:
- containerPort: 6379
name: redis6379
env:
- name: ALLOW_EMPTY_PASSWORD
value: "yes"
- name: REDIS_PASSWORD
value: "redis"
# ， docker
volumeMounts:
- name: redis-persistent-storage
mountPath: /data
volumes:
#
- name: redis-persistent-storage
nfs:
path: /k8s-nfs/redis/data
server: 192.168.8.150# This mounts the nfs volume claim into /mnt and continuously
# overwrites /mnt/index.html with the time and hostname of the pod.
apiVersion: v1
kind: Deployment
metadata:
name: busybox-deployment
spec:
replicas: 2
selector:
name: busybox-deployment
template:
metadata:
labels:
name: busybox-deployment
spec:
containers:
- image: busybox
command:
- sh
- -c
- 'while true; do date > /mnt/index.html; hostname >> /mnt/index.html; sleep $(($RANDOM % 5 + 5)); done'
imagePullPolicy: IfNotPresent
name: busybox
volumeMounts:
# name must match the volume name below
- name: nfs
mountPath: "/mnt"
volumes:
- name: nfs
persistentVolumeClaim:
claimName: nfs-pvc