企业容器云持久化存储方案设计及难点解读

企业容器云持久化存储方案设计及难点解读

容器迁移过程中，同时需要对数据也进行迁移，需要一套数据扩容和管理的机

制来满足有状态服务的数据存储需要。

在面向有状态的容器服务时，需要考虑以下几个方面的数据持久化需求：

1、容器对应的存储卷在进行故障恢复时，会带来卷的挂载和卸载。为了保女整

个生产环境的高可用，卷的挂载和卸载一方面需要具有足够的稳定性，同时也

需要考虑性能需求，避免应用延迟。

2、存储卷快照管理需求。传统的存储卷快照策略主要从资源角度进行管理，而

容器的存储卷往往动态分配而来，快照策略需要与容器应用备份需求保持一

致。

3、容量扩容需求：随着容器应用数据的增长，存储卷容量需要考虑扩容的能

力，最大程度避免对应用运行的影响。

4、运维管理需求：随着容器有状态应用的增长，对传统存储运维工作也会带来

挑战，整体方案需要兼顾运维敏捷和安全。

5、分布式存储需求：狼行创新业务的扩展能力通常都是横向扩展的，需要容器

云具备横向扩展的能力，需要引入分布式存储架构部署在容器云平台上。为了

能更好的解决大家在容器云持久化上的需求及方案设计下遇到的建设难点，twt

社区不久前特别邀请了某大型银行的容器云专家以及SmartX的容器持久化专家

在线辅导答疑。本文对交流内容进行总结，供更多同行参考。分为四个部分：

容器持久化存储建设难点和关注点、容器持久化存储的建设方案重点考虑的

涉及层面、容器持久化技术层面的选择、交流总结共识。

一、容器持久化存储建设难点和关注点

1、企业容器云为支持有状态应用的容器应用部署，存储设计时需要考虑哪些

因素？

©rechen招商银行云引算架构师:

有状态应用的状态可细分指拓扑状态、存储状态。其中拓扑状态指应用的多个

实例之间不是对等关系，这些应用实例，必须按照某种顺序启动。存储状态则

是指应用的多个实例分别绑定了不同的存储数据，对于这些应用实例来说。当

应用因为某些原因导致了宕机，重启后依旧可以正常的读取到数据。在容器云

上部署的有状态应用，其部署需求有：维持稳定且唯一的网络标识，提供稳定

持久的存储，提供有序和优雅的部署和伸缩能力，提供有序和自动的更新能

力。因此存储设计时，要综合考虑到有状态应用的特征进行设计，譬如在容器

云上部署数据库这类有状态应用，和部署日志监控这类有状态应用就有不同的

设计维度和优先级。存储产品的选型优先考察稳定、安全、性能和API能力。

@asdf-asdfcloudstone研究学者：

当前有状态应用的容器应用部署，如果有能力应修改应用。使其状态保存在缓

存服务器类似Rcdiscluster中，相关日志统一进入ELK,或者Kafka完成

持久化。这样存储设计相对简单，只要保证ELK和Redis的存储容量和访问

速度。如果无法修改应用，需要挂载一个持久化卷，来持久化数据。使数据可

以在不同节点漂移，需要所有主机对存储的访问权限，这个又会出现存储访问

风险。在实际业务场景，把存储分多个区域，挂载到对应区域的主机，进行区

别访问，避免访问风险。

2、持久化存储选择集中式存储，还是分布式存储？

@rcchcn招商银行云计算架构师：

容器云的持久化存储的选型，还是要根据承载的工作负载进行具体分析。譬如

在容器云上部署关系型数据库，且数据库的数据是重要的业务系统数据，则选

择集中式存储为宜。如果是业务应用系统的日志，或者是配置文件，则建议优

先选择分布式存储，在扩展性和成本收益上更佳。

@nawangSmartX产品经理：

集中式存储：可以在Kubernetes中使用已有的FC-SAN或NAS。然而，传统

存储不可弹性扩展、依赖专有硬件、运维管理相对复杂等特点与云原生所要求

的敏捷背道而驰，它们并不是K8s的首选。

分布式存储：分布式存储天然具有横向扩展能力，在性能和高可用方面远优于

集中式存储，非常适合应对大规模虚拟化场景。不过在实际的使用过程中，大

部分分布式存储的性能和稳定性都难以达到生产级别的标准，这使得很多运维

团队不敢轻易地部署分布式存储产品。

二、容器持久化存储的建设方案重点考虑的涉及层面

1、金融行业企业级容器持久化存储方案，开源和商用应该如何选择？优劣势

分析？

©rechen招商银行云计算架构师：

金融行业企业级容器持久化存储方案，建议从稳定性、安全性维度上，选择商

用产品。选择走开源路线的话，则必须要自建研发团队补齐稳定性和安全能

力，以及高水平的运维团队，这样综合成本上看，是投入大、风险高且见效

慢，不利于金融行业提升业务核心竞争力。

@nawangSmartX产品经理：

建议选择商用型存储方案。

商用型存储方案，以lOMesh云原生存储产品为例，相较Ccph、GlusterFS

类开源架构的分布式存储，优势有以下几点：

1）掌握核心代码，可控性更强。

开源产品的演进由社区主导，厂商无法根据客户需要快速落地功能；出现严重

问题时也不能特别快速地响应，往往需要等待社区的修复。lOMesh选择自主研

发的形式，充分把控产品质量和功能，可以根据众多客户的实际需求迭代产

品，也能在出现问题时提供本地研发级别的快速响应，为用户业务运转提供强

有力的保证。

2）更灵活。

通过元数据服务实现数据副本的精确放置，可以形成更加灵活的副本分配策

略，并按照资源进行调整副本分配位置，而不是简单打散；

3）性能更高。

可以实现计算与存储1/0路径的深度融合，发挥更高的性能。

2、容器持久化存储方案重点考虑哪些层面设计？

@nawangSmartX产品经理：

1.云原生存储系统需要能够良好的运行在各种不同服务商提供的公有云环境或

私有云环境，能够很好地和其他云原生基础设施配合，例如云原生数据库，使

得云原生数据库可以真正的在公有云和私有云都能够得到一致的用户体验。

2.云原生存储系统需要为运维人员提供相同接口和运维方式，即运行在K8s

中，使用K8s的工具进行运维和管理，具备容器化部署、自动运维、声明式接

口等特征，降低运维团队的负担。

3、如何选择合适的容器云持久化存储方案，Rook+Ceph用于生产环境有

何风险？

@nawangSmartX产品经理：

开源产品的演进由社区主导，厂商无法根据客户需要快速落地功能；出现严重

问题时也不能特别快速地响应，往往需要等待社区的修复。

而商用型存储方案，尤其是厂商具备自主研发能力的，可以充分把控产品质量

和功能，可以根据众多客户的实际需求迭代产品，也能在出现问题时提供本地

研发级别的快速响应，为用户业务运转提供强有力的保证。

4、容器数据备份有哪些好的方案？容器全备份？还是提取容器中的数据来备

份？

@rechen招商银行云计算架构师:

需对容器的数据做好分层规划，容器镜像放在镜像仓库中，不必做备份；容器

实例存取的数据，如果是存储在分布式文件系统中，则做好分布式文件系统的

高可用和备份即可。

@强哥之神上汽云计算中心容器云架构师及技术经理：

容器数据备份，首先是明确是哪些数据，是日志还是应用产生的数据，还是应

用需要依赖的数据。

如果是日志数据，就可以对接日志平台，也可通过fluentd等日志组件收集；

如果是应用产生的数据，那么最好需要通过持久化进行备份到分布式存储中;

如果是应用依赖的数据，比如中间件数据库等应用，也可以持久化到分布式存

储中，但这种情况更多会追求存储性能，就需要用本地卷如LocalPV来实现，

但本身需要依赖应用自身做好数据的同步，比如MySQL的主备通过binlog同

步。

@half_life上海骥步科技有限公司研发总监：

容器的数据备份，其实就是有状态应用在k8s的备份问题（不包括容器的境

像），个人认为实际上已经不能把容器本身以及应用的数据分开来了。备份的

时候，应该把应用以及应用相关的资源，如configmap,secret,pv.

pvc,service,以及pv里面的数据，一起备份下来，并且拷贝或者上传到

第二存储，同主存储隔离开来。

目前国外主流的产品有kasten的K10,PortworxPXbackup,以及社区的

开源项目velero。这些产品的主流做法，就是把应用的资源以及数据打包，

一起备份到S3对象存储，或者NFS等第二存储。其中，PV,PVC还可以

抓取CSI快照，然后对快照进行备份，或者对快照进行有选择的数据导出。之

所以这样做，是因为在k8s容器时代，容器是一个动态变化的资源，例如正在

运行在哪个node上、配置的参数、版本等等信息都可能是变化的。而最关键

的数据，是靠PV,PVC这样的资源来描述的。换句话说，PV,PVC其实

就记录了容器同应用数据的mapping关系。在备份的时候，如果容器跟底下使

用的存储（如分布式存储）分开备份，这样可能带来几个问题：

容器的备份时间跟存储的备份时间不一致，这样就造成版本的不一致。

存储的备份一般是针沟存储本身的volume/LUN进行备份，恢复的时候，还要

处理volume/LUN同PV的关系。

一个集群可能使用不止一个存储，那备份的时候还要考虑不同存储的备份策

略。

一个分布式存储可能而多个集群供应存储，对某个集群的某个应用的细粒度的

数据恢复来说，可能不好处理。

总之，如果备份时候而容器和存储分开考虑，那还是基本沿用了虚机时代备份

的思路，在容器时代要用的好可能有点困难。在备份的时候，把应用相关的资

源一起打包备份，其实就是把资源跟数据的关系在同一个时间点一起备份下

来，形成一个比较完整的可用的恢复点，将来恢复时候，也是根据应用的颗粒

度来进行恢复的。

@笑笑财险系统工程师：

备份整个容器肯定不现实。提取容器中的数据也不用。因为如果是应用需要持

久化存储，那么就备份持久化存储上面的数据就好。比如你是商业存储提供持

久化存储，那么可以通过存储层面去做备份。如果是用Ceph这些分布式存

储，那么可以利用Veritas结合分布式存储来备份。

@guojin_cib兴业软件架构设计师：

这里暂且只讨论容器数据备份，而不涉及集群的备份和恢复。

容器里面实现持久化存储的方式比较多，一方面通过hostpath挂载，隐射宿

主机的目录到容器的目录，另一方便通过通过storage绑定挂载持久卷到容器

的任何目录。还有通过将NFS目录作为容器的卷挂载的，

当谈到备份数据时，上面的方法都存在一个相同的问题-如果容器内的数据在

备份过程中发生变更，那么就出现了数据的不一致性，当然我们可以通过关闭

卷的读写来获得数据的一致性，不过关闭卷来备令，会导致业务连续性的中

断。

这里建议在k8s集群中，把有状态服务的信息存储在数据中，独立于容器的文

件的系统。

这样就可以按照常规的方式备份数据，比如快照。

这里介绍几个开源项目一个是openebs,比较火的开源的云原生的存储。另

外一个就是velero项目，可对集群资源备份和恢复。

©zhuqibsMed软件开发工程师：

首先，容器中如果有数据，有三种方式放置，top、hostpath和

storageclass。

其次，如果要备份容器内的数据，如果使用tmp显然不可能，如果是

hostpath,需要到指定的节点上去备份，但容器环境中，pod会切换，生产

环境不会使用。

所以，生产的容器环境数据要备份，必然容器中的数据是storageclass,也

就是说，要么是分布式存储，要么是集中存储，而这种存储，通常都是多副本

的，多副本一般是无须备份的。

如果，真的一定要备份，请在容器所涉及应用的逻辑层，进行备份比较合适，

比如如果是Elasticsearch,可以用reindex,把索引数据拉到另一个集

群。

©sabotageoxford研发工程师：

设计上需要把容器尽可能做的无状态服务，状态，’呆存在外部公共存储池中或云

组件里，这样才能实现容器任意调度，迁移，按需扩容缩容。状态包括内存状

态（保存在缓存池），数据库（保存在云数据库），文件（保存在分布式文件

系统）

典型如web服务的session信息，要么存储于公共的kv存储里，要么生类

似jwttoken等分布式鉴权，总之需要避免在容器内部保留超过一次交互以外

的数据。

容器最大优势是便于迁移缩放，部署灵活，带上数据就失去了这个迁移能力，

所以不是说不能存数据，而是从架构层面把有状态服务放容器就是错的。

@sf7071某大型银行云计算研发工程师：

容器中的数据要持久化，一般会挂载宿主机上的本地存储，或者分布式存储，

即使容器销毁了，数据仍然在，新建的容器照样挂在原来的存储就能恢复数

据。在容器云上部署数据库，部署架构也要是高可用的集群，集群各节点间应

该有数据同步机制。所以，备份容器是没用的，容器是静态的镜像运行起来后

的实例，容器里本身不应该存放持久化的数据。

©jakeyyu三甲医院系统架构师：

容器备份能不能采用快照技术，如果能够采用快照技术，可以考虑直接备份容

器，最方便的。

5、企业如何能解决容器数据持久化及数据备份恢复问题？

@北京不眠夜产品经理：

通过容器平台CSI标准接口调用现有存储资源。常见存储有NAS、IP-

SAN、Ceph等。通过PV、PVC完成挂载。

数据备份/恢复

容器平台侧，实现对平台数据库、ETCD的数据库高可用即可。同时，借助传

统备份软件实现数据备份，增加一层保险。

应用软件侧，应用程序有镜像做背书，数据库非容器化，参照传统数据备份方

式。如数据库容器化，需要看平台是否提供相应能力。

@jakeyyu三甲医院系统架构师：

设置运行容器的镜像进行数据同步，或者采用容器快照技术

三、容器持久化技术层面的选择

1、容器使用nfs存储对接时，能否限制命名空间pv的大小？

©rechen招商银行云计算架构师：这和NFS服务器的能力有直接关系，建议

选择商用产品，譬如nexenta。

©nawangSmartX产品经理：

NFSPV配额的限制需要由NFS的服务端来控制，如在服务端限制具体共享卷

目录的配额。

2、针对企业容器云持久化存储方案的存储需求，如何选择Kubernetes的哪

种卷Volume?

©rechen招商银行云计算架构师：

需要综合根据IAAS层的存储服务的支持和容器云的应用存储需求而定。

1）对于有状态应用的容器应用部署，要考虑其对计算和存储性能的需求，选

择兼具高性能、安全的灵活性的基础架构硬件设备。

2）对于容器云有状态应用的数据持久化管理，尽量采用CST插件的方式进行

管理，无论是块存储还是文件存储，都可以通过CSI提供的iSCSI、NFS

等方式去使用。

3）应用的配置数据存储，主要是用来管理容器，可以借助现有的存储来实

现，主要是一些配置数据和日志记录等管理数据，譬如可以使用ETCD和配置

中心来存储。

4）应用自身的数据存储，是应用真正需要保存的数据，需要写入持久化的

Volume数据卷，必须确保数据能被不同的节点所访问，且数据存储接口以文

件形式会更适应应用访问。

5）容器持久化存储一般可以通过两种形式来实现：一是本地盘的形式，优

势是简单易用，缺点是难以迁移共享以及伸缩；二是共享存储集群的形式，优

势是数据共享，可以提供多种存储接口，可以弹性伸缩，缺点是架构稍显复

杂。

©nawangSmartX产品经理：

一般来说FileSystem类型的卷更通用，由存储服务来负责管理文件系统，用

户只需要读写指定的目录即可；但是如果需要更高的灵活性以及性能，可以采

用Block类型的卷，在容器中会挂载为一个块设备，用户可以对块设备进行分

区、创建文件系统、或是直接读写都是可以的。

对于云原生时代的存储系统选型，可以参考这篇文章《云原生时代需要什么样

的存储系统》。

3、应用容器化后，建议日志是落盘后再采集还是直接通过网络发到外部呢？

©Hsia某消费金融SA：

三种常见日志收集解决方案

1）每个app的镜像中都集成日志收集组件:

优点：部署方便，kubernetes的yaml文件无须特别配置，可以为每个app

自定义日志收集配置

缺点：强耦合，不方便应用和日志收集组件升级和维护且会导致镜像过大

2）单独创建一个日志收集组件跟app的容器一起运行在同一个pod中：

优点：低耦合，扩展性强，方便维护和升级

缺点：需要对kubernetes的yaml文件进行单独配置，略显繁琐

3）将所有的Pod的日志都挂载到宿主机上，每台主机上单独起一个日志收集

Pod：

优点：完全解耦，性能最高，管理起来最方便

缺点：需要统一日志收集规则，目录和输出方式

@actorl68中国联通软件研究院研发工程师：

可以考虑的方面：

1）性能考量

涉及到读写盘、读写网络接口的性能问题，涉及到大量容器的读写时，10孰

高孰低，是否会因为E志导致整体程序崩溃等。相比而言，本地落盘读写速速

度快，但对容器云平台来说，本地落盘容器日志的处理和收集又相对繁琐，

如：如何动态搜集日志数据、何时清理本地盘数据？

2）数据量考量

如果日志量非常大，因为日志导致的带宽增加性吩比会更低。

考虑以上两个方面，我们的方案是：日志先本地存储，后再进行转储搜集。

@ruanyirong安全架构师：

目前我们内部推荐的方案是采用双日志方案，保存两份日志，可进一步保障日

志数据安全，方便后续日志分析和故障定位。一方面容器应用的日志可以输入

出到标准输出或文件中，输出到标准输出的日志，可通过ELK组合开源工具收

集到ElasticSearch集群中供后续查询，如果应用无法输出到标准输出，则

使用sidecar方式直接发送到ElasticSearch集群，通过另外的日志服务系

统提供日志查询服务；另一方面日志文件持久化到共享存储中，支持通过服务

器查看。

@JanXCnec系统架构师：

建议直接网络发出吧，只是占用网络i。，可以配置单独的网卡走日志流曷.

写入到es或其他日志存储分析工具中进行分析。如果先落盘，最终还是要采

集分析的，对于日志生产端，同时占用网络和存储的ioo需要注意的是，不

管走网络，还是采集落盘在进行分析，都联系与生产读写及网络做分开，特别

是高负载的情况。但是网络发出实现上应该比较复杂，增加节点，而且万一有

问题，会出现日志丢失的情况。落盘采集简单可靠，方案成熟，要求不是特别

好的话，生产环境落盘采集感觉会好一些。

@Steven99软件架构设计师:

依我个人观点，日志直接发出去。但这个方案通常会复杂些。要保证日志发送

失败不会导致服务异常。就优先级别来说，前提是保障业务运行。日志可以

丢，服务不能受影响。至于选择哪种方式，考虑自身的能力和整体的架构和组

件配置。

1）落盘是简单的方式，通常不会带来额外影响，除非TO有问题。

2）在业务里面直接发送日志到外部，比如通过消息方式，需要和消息服务器

建立连接，在服务内需要引入日志消息发送组件（也就是说需要先封装日志发

送client组件），连接可能会断开，网络io也可能会是瓶颈，等等，麻以

整体方案会复杂化不过这个方案是考虑整体趋势和融合架构的结果，有效率方

面的考虑，日志发送通常也要考虑批量处理等这个方案有个好处是基于实时事

件处理的事中处理可以构建起来，所以说是从整体方案来考虑的。

3）容器可以直接打印日志到标准输出，从标准瑜出采集然后发送到日志中

心，目前我们采用的是这种方案。这种方案也相对简单不过依然需要注意的问

题是，日志信息一定要格式标准化，分级，运行时可调整记录级别。

@强哥之神上汽云计算中心容器云架构师及技术经理：

容器日志收集有三种方案：

第一种，在Node上部署loggingagent,将E志文件转发到后端存储里‘呆存

起来，这里的核心就在于loggingagent,它一般都会以DaemonSet的方式

运行在节点上，然后将宿主机上的容器日志目录挂载进去，最后由logging-

agent把日志转发出去。举个例子，我们可以通过Fluentd项目作为宿主机上

的logging-agent,然后把日志转发到远端的ElasticSearch里保存起来供

将来进行检索。在Node上部署loggingagent最大的优点，在于一个节点只

需要部署一个agent,并且不会对应用和Pod有任何侵入性。所以，这个方

案，在社区里是最常乐的一种。但是也不难看到，这种方案的不足之处就在

于，它要求应用输出的日志，都必须是直接输出到容器的stdout和stderr

里。

所以，Kubernetes容器日志方案的第二种，就是对这种特殊情况的一个处

理，即：当容器的日志只能输出到某些文件里的时候，我们可以通过一个

sidecar容器把这些E志文件重新输出到sidecar的stdout和stderr上，

这样就能够继续使用第一种方案了。在这种情况下，你用kubectllogs命令

是看不到应用的任何E志的。而且最常用的方案一，也是没办法使用的。那么

这个时候，我们就可以为这个Pod添加两个sidecar容器，分别将上述两个

日志文件里的内容重新以stdout和stderr的方式输出出来。这时候，你就

可以通过kubectllogs命令查看这两个sidecar容器的日志，间接看到应用

的日志内容了。由于sidecar跟主容器之间是共享Volume的，所以这里的

sidecar方案的额外性能损耗并不高，也就是多占用一点CPU和内存罢了。

但需要注意的是，这时候，宿主机上实际上会存在两份相同的日志文件：一份

是应用自己写入的；另一份则是sidecar的stdout和stderr对应的

JS0N文件。这对磁盘是很大的浪费。所以说，除非万不得已或者应用容器完

全不可能被修改，否则我还是建议你直接使用方案一，或者直接使用下面的第

三种方案。

第三种方案，就是通过一个sidecar容器，直接把应用的日志文件发送到远程

存储里面去。也就是相当于把方案一里的loggingagent,放在了应用Pod

里。在这种方案里，你的应用还可以直接把日志瑜出到固定的文件里而不是

stdout,你的logging-agent还可以使用fluentd,后端存储还可以是

ElasticSearch。只不过，fluentd的输入源，变成了应用的日志文件。一

般来说，我们会把fluentd的输入源配置保存在一个ConfigMap里。Fluentd

容器使用的输入源，就是通过引用这个ConfigMap来指定的。需要注意的是，

这种方案虽然部署简单，并且对宿主机非常友好，但是这个sidecar容器很可

能会消耗较多的资源，甚至拖垮应用容器。并且，由于日志还是没有输出到

stdout上，所以你通过kubectllogs是看不到任何日志输出的。

综合对比以上三种方案，我比较建议你将应用日志输出到stdout和

stderr,然后通过在宿主机上部署logging-agent的方式来集中处理日志。

这种方案不仅管理简单，kubectllogs也可以用，而且可靠性高，并且宿主

机本身，很