本文引见了容器云存储设计所须要的基本常识，使读者能对此构成比拟平面的认知以及了解设计的重点方向，并进一步引见了Kubernetes存储的设计与架构。
1、容器平台存储的基本常识
存储作为容器平台关键的组成局部，保证着容器数据的安保，在整个系统中具有无足轻重的作用，是整个设计的重中之重。
容器中数据的存储是暂时性的，当容器隐没的时刻，数据也会随之隐没，起初就有了耐久化存储的钻研;在Kubernetes平台上，Pod中同时多个容器运转，经常须要这些容器共享数据存储，来保证数据的安保性。Kubernetes形象出Volume对象来处置存储方面的疑问。Docker也有Volume的概念，但对它只要大批且松懈的治理。在Docker中，Volume是磁盘上或许另外一个容器内的一个目录。起初新增了Volume生命周期的治理，以及Volume的驱动程序，只管性能还十分有限。
Kubernetes卷具有明白的生命周期——与包裹它的Pod相反。因此，卷比Pod中运转的任何容器的存活周期都长，在容重视新启动时数据也会失掉保管。当然，当一个Pod不再存在时，卷也将不存在。Kubernetes可以支持许多类型的卷，Pod也能同时经常使用恣意数量的卷。
卷的**是蕴含一些数据的目录，Pod中的容器可以访问该目录。特定的卷类型可以选择这个目录如何构成的，并能选择它支持何种介质，以及目录中寄存什么内容。经常使用卷时，Pod申明中须要提供卷的类型(.spec.volumes字段)和卷挂载的位置(.spec.containers.volumeMounts字段)。容器中的进程能看到由它们的Docker镜像和卷组成的文件系统视图。Docker镜像位于文件系统档次结构的根部，并且任何Volume都挂载在镜像内的指定门路上。卷不能挂载到其余卷，也不能与其余卷有硬衔接。Pod中的每个容器必定独立地指定每个卷的挂载位置。
容器存储的类型
容器架构经常使用到的三种存储：
(1)镜像存储
这个可以应用现有的共享存储，相似于虚构化环境中虚构机镜像的散发包全机制。容器镜像的长处在于其存储容量相较于完整的虚构机镜像小了很多，由于不会复制操作系统代码。此外，容器镜像的运转在设计之初便是固定的，因此可以更高效地存储、共享。但也因此，容器镜像无法存储灵活运行程序的数据。
(2)性能数据存储
这些性能数据用来治理容器，可以借助现有的存储来成功，关键是一些性能数据和日志记载等治理数据。
(3)运行数据存储
这些数据是关键的、暂时的，也是最难存储上去的。相比虚构机，容器的设计寿命更短，一旦容器销毁，一切的暂时存储都会随之隐没。因此，运行真正须要保管的数据，可以写入耐久化的Volume数据卷。由于以微服务为主的容器运行多位散布式系统，容器或许在多个节点中灵活地启动、中止、伸缩或许迁徙。因此，当容器应用具有耐久化的数据时，必定确保数据能被不同的节点所访问。另一方面，容器是面向运行的运转环境，数据通常要保管到文件系统中，即存储接口以文件方式更顺应运行访问。
数据耐久化存储数据量须要提早做好布局，关于容器迁徙的支持也雷同须要提供存储方面的支持。须要依据业务不同的需求，来提供不同的存储。etcd会存储平台的形态和性能消息，那么对性能、安保、稳固的要求就比拟高。
平台中存储的运行场景
Kubernetes中关于存储的经常使用关键集中在以下几个方面：
在Kubernetes中部署和运转的服务大抵分为：
(1)有形态服务
Kubernetes经常使用ReplicateSet来保证一个服务的实例数量，假设说某个Pod实例由于某种要素挂掉或许解体，ReplicateSet会立刻用这个Pod的模版来代替它。由于是有形态的服务，新Pod与旧Pod一摸一样。此外Kubernetes经过Service(一个Service前面可以挂多个Pod)对外提供一个稳固的访问接口，成功服务的高可用。
(2)普通有形态服务
和有形态服务相比，它多了形态保管的需求。Kubernetes提供了以Volume和PersisettentVolume为基础的存储系统，可以成功服务形态的保管。
(3)有形态集群服务
和普通有形态服务相比，它多了集群治理的需求。要运转有形态集群服务要处置的疑问有两个，一个是形态保管，另一个是集群治理。Kubernetes为此开发了StatefulSet，繁难有形态集群服务在Kubernetes上部署和治理。
容器云存储设计的关键性
数据是一个企业关键的资产，如何应用好数据，可以成功企业的昌盛，如何保管好数据，则是保证企业昌盛的坚强后台。因此，在平台树立前的布局阶段，必定做好充沛的技术预备和名目调研，必定将数据的关键性优化到一个关键的层面来惹起注重。
数据是企业的关键资产，保证数据不失落，数据完整，数据分歧，才干更好的展开门务。容器和虚构机或物理机技术成功并重不同，容器并重有形态运行，要支持有形态运行，数据存储必定基于业务需求提早思考和布局。
容器云是基础平台，触及平台组件、镜像、运行、两边件等多个方面，每个方面都或许有不同的存储需求。要取得现实的性能和结果，须要片面的思考每个方面，存储等作为基础设备资源，更是必无法少的局部。
容器是用来承载运行的，运行各个档次的数据具有潜在的价值，捕捉并处置、存储、剖析这些数据是失掉价值的步骤。因此，运行数据的耐久化是容器云平台撑持业务运行的关键的基础才干之一。建好基础，才干好地服务运行。
2、Kubernetes中几种经常出现的存储系统
从Kubernetes官网提供的数据看来，Kubernetes支持的Volume Plugin如下表所示：
Kubernetes曾经提供了十分丰盛的Volume和PersistentVolume插件，可以依据自身业务的个性，经常使用这些插件给容器提供存储服务。每一种Plugin的经常使用方法和留意事项参见：
容器存储接口(Container StorageInterface，CSI)是一项跨行业规范建议，旨在降落云原生活储开发上班的门槛，从而进一步确保兼容性水平。Kubernetes中CSI，将新分卷插件的装置流程简化至与装置Pod相当，并准许第三方存储供应商在无需接触**Kubernetes代码库的前提下开发自己的处置打算。
3、耐久化存储设计
前面提到了，数据是企业展开门务，进一步失掉价值的源泉，是**资产。关键的数据必定做耐久化存储并依照监管/业务要求启动备份。容器耐久化存储普通可以经过两种方式来成功：第一，是本地盘的方式，长处是繁难易用，缺陷是难以迁徙共享以及伸缩;第二，是共享存储集群的方式，长处是数据共享，可以提供多种存储接口，可以弹性伸缩，缺陷是架构稍显复杂。针对不同场景，耐久化存储须要有不同的选用战略：
4 Kubernetes存储的设计与基本架构
4.1 Persistent Volume与Persistent Volume Claim概念引见
一个运转中的容器，在缺省状况下，对文件系统的写入，都是出当初其分层文件系统的可写层的(copy-on-write)。当迁徙的运行程序从开发到消费环境的时刻，开发人员面临着渺小的应战。当容器挂掉、解体或许运转完结时，任何与之相关的数据都会失落。为了处置这个疑问引发的数据失落，咱们须要将数据存储耐久化，也可以称为PersistentVolume。
Kubernetes经常使用两种资源治理存储：
Kubernetes中的Volume则是基于Docker启动裁减，经常使用 DockerVolume挂载宿主机上的文件目录到容器中。普通说来，Kubernetes中的Pod经过如下三种方式来访问存储：
(1)间接访问
该方式移植性较差，可裁减才干差，把Volume的基本消息齐全泄露给用户，有重大的安保隐患，同时须要协调不同user对Volume的访问。
(2)静态provision
(3)灵活provision
很显著，灵活供应比静态供应灵敏更多，而且这种方式还解耦了Kubernetes系统的计算层和存储层，更关键的是它给存储供应商提供了可插拔式的开发模型，存储供应商只要要依据这个模型开发相应的卷插件即可为Kubernetes提供存储服务。有三种方法成功：
In-tree Volume Plugin
Out-of-tree Provisioner
Out-of-tree CSI Driver
第一种，Kubernetes外部代码中成功了一些存储插件，用于支持一些干流网络存储。
第二种，假设有官网插件不能满足要求，存储供应商可以依据须要去定制或许优化存储插件并集成到Kubernetes系统。
第三种，是容器存储接口CSI，是Kubernetes对外放开的存储接口，成功这个接口即可集成到Kubernetes系统中。社区之前曾经发表将不再对intree/out of tree继续开发，并将已有性能所有迁徙到CSI上，所以关于存储供应商和经常使用者来说，第三种CSI打算更值得介绍。
普通来说，PV和PVC的生命周期分为5个阶段：
(1)Provisioning，即PV的创立，可以间接创立PV(静态方式)，也可以经常使用Storage Class灵活创立;
(2)Binding，将PV调配给PVC;
(3)Using，Pod经过PVC经常使用该Volume;
(4)Releasing，Pod监禁Volume并删除PVC;
(5)Reclaiming，回收PV，可以保管PV以便下次经常使用，也可以间接从存储中删除。
依据这5个阶段，Volume的形态有以下4种：
4.2 基础Kubernetes存储架构
Kubernetes存储在设计的时刻遵照申明式(Declarative)架构。同时为了尽或许多地兼容各种存储平台，Kubernetes以in-treeplugin的方式来对接不同的存储系统，满足用户可以依据自己业务的须要经常使用这些插件给容器提供存储服务。同时兼容用户经常使用FlexVolume和CSI定制化插件。相比拟于DockerVolume，支持的存储性能愈加丰盛和多样。
Kubernetes中mount一个PV的基本环节包括：
(1)用户经过API创立一个蕴含PVC的Pod;
(2)Scheduler把这个Pod调配到某个节点Node;
(3)节点Node上的Kublet开局期待Volume Manager预备Device;
(4)PV controller调用相应VolumePlugin(in-tree或许out-of-tree)，创立PV，并在系统中与对应的PVC绑定;
(5)Attach/Detach controller或许Volume Manager经过VolumePlugin成功Device挂载(Attach);
(6)Volume Manager期待Device挂载终了后，将卷挂载到节点指定目录;
(7)Node节点上的Kublet此时原告知Volume曾经预备好后，开局启动Pod，经过Volume mapping将PV挂载到相应的容器中去。
Kubernetes存储架构设计图