、ストレージリソースを管理する方法Kubernetes
ボリュームは理解して
私たちはしばしば言う：コンテナとポッドが短いです。
含意は、彼らは非常に短いライフサイクルであってもよいし、頻繁に作成および破棄されていることです。ファイル・システム・データ内のコンテナに格納されて破壊された容器は、クリアされたとき。
永続的なデータストレージコンテナのKubernetesボリュームを使用することができます。
ライフサイクルの体積が容器から独立している、容器内のポッドは破壊され、再構築が、ボリュームは保持されてもよいです。
基本的に、Kubernetesボリュームはドッカーボリュームに似ているディレクトリです。ボリュームポッドをマウントする場合は、すべてのコンテナにポッドは、ボリュームにアクセスすることができます。KubernetesボリュームもなどemptyDir、ホストパス、GCE永続ディスク、AWS弾性ブロックストア、NFS、セファロ、参照の完全なリストを含む複数のバックエンドタイプをサポート
https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes
ボリュームは、さまざまなバックエンドの抽象化、データの読み書きが、それは難しいまだクラウド内のローカルノードのファイルシステムに格納されて最終的に心配する必要はありません、ボリュームデータの使用中に容器を提供します。これは、ボリュームのすべてのタイプのためだけのディレクトリである、です。
二つは、ボリュームの種をkubernetes
1、emptyDir
emptyDirボリュームは、最も基本的なタイプです。その名前が示すように、emptyDirボリュームは、ホスト上の空のディレクトリです。
ポッドがないため、コンテナのemptyDirボリュームは耐久性です。ポッドがノードから削除されると、ボリュームの内容は削除されます。しかし、コンテナは、まだポッド、影響を受けていないボリュームながら、破壊された場合にのみ。
：つまりemptyDirボリュームのライフサイクルポッドと一致。すべてのコンテナでのポッドは、独自のマウントパスを割り当てることができ、ボリュームを、共有することができます。次のようにここでは一例として、設定ファイルによって実施することがemptyDir：
ここでは、生産者 - 消費者のシナリオをシミュレートします。ポッドプロデューサーは二つの容器を持っており、消費者は、彼らがボリュームを共有しています。ボリュームプロデューサーは、データを書き込むこと責任がある、消費者データをボリュームから読み込まれます。
①底ボリュームファイルボリューム共有ボリュームのemptyDirタイプを定義します。
共有ボリュームマウント/ producer_dirディレクトリに②プロデューサ容器。
③エコーによるプロデューサーはハローファイルにデータを書き込みます。
共有ボリュームのマウント/ consumer_dirディレクトリへ④消費者のコンテナ。
ファイルハロー猫からデータを読み出すことにより、⑤消費者。
emptyDir一時ディレクトリをホスト上で作成され、便利ポッドで提供することができる利点が貯蔵容器、追加の構成を共有しました。しかし、それはポッドが存在しない場合、emptyDirは無いだろう、持続性を持っていません。この特徴によれば、そのような民生用生産上記実施形態のように、一時的な共有ストレージ・スペース必要なシーンのために特に適した容器にemptyDirポッド。
2、ホストパス巻
ホストパスボリュームの役割は、ドッカーホスト・ファイル・システムにある既存のディレクトリポッドコンテナにマウント。それは実際にポッドの使用を制限し、カップリングポッドおよびノードを増加させるので、ほとんどのアプリケーションは、ホストパスボリュームを使用しません。しかし、これらのアプリケーションは、アクセスKubernetesを必要とするか、またはドッカー内部データ（コンフィギュレーションファイルとバイナリライブラリー）はホストパスを使用する必要があります。
次は、ボリュームの関連セクションを見ています：
これは、3つのホストパスボリュームK8S、証明書とPKIを定義し、それぞれのディレクトリは/ etc / kubernetesは、/ etc / SSL /証明書とは/ etc / PKIをホストします。
ポッドが破壊された場合、ホストパス対応するディレクトリも、この点、ホストパス永続emptyDirよりも強いが保持されます。しかし、ホストがクラッシュしたら、ホストパスも訪問することができません。
3、外部ストレージプロバイダ
このようAWS、GCE、Azureの他のパブリッククラウドとしてKubernetesに展開した場合、クラウドはハードディスクボリュームとして直接使用することができ、以下はAWS弾性ブロックストアの例です。
ポッドにおけるESBのボリュームを使用するには、最初にAWSで作成し、次にボリューム-IDによって参照されなければなりません。他のクラウドハードドライブの使用量は、各パブリック・クラウド・ベンダーの公式文書を参照することができます。
Kubernetesボリュームは、次のようなセファロ、GlusterFS等として、主流分散メモリを使用することができるセファロの例です。
CEPHファイルシステム/いくつかの/パスは、/ IN /側面/ディレクトリパスがコンテナ/テストCEPHを取り付けることであるcephfs。
相对于 emptyDir 和 hostPath，这些 Volume 类型的最大特点就是不依赖 Kubernetes。Volume 的底层基础设施由独立的存储系统管理，与 Kubernetes 集群是分离的。数据被持久化后，即使整个 Kubernetes 崩溃也不会受损。
当然，运维这样的存储系统通常不是项简单的工作，特别是对可靠性、高可用和扩展性有较高要求时。
Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。
4、PV & PVC
Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。
拿前面 AWS EBS 的例子来说，要使用 Volume，Pod 必须事先知道如下信息：
（1）当前 Volume 来自 AWS EBS。
（2）EBS Volume 已经提前创建，并且知道确切的 volume-id。
Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息：
（1）要么询问管理员。
（2）要么自己就是管理员。
这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。
Kubernetes 给出的解决方案是 PersistentVolume 和 PersistentVolumeClaim。
PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。
PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV。
有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。
Kubernetes 支持多种类型的 PersistentVolume，比如 AWS EBS、Ceph、NFS 等，完整列表请参考：https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes