容器迁移过程中，同时需要对数据也进行迁移，需要一套数据扩容和管理的机制来满足有状态服务的数据存储需要。
在面向有状态的容器服务时，需要考虑以下几个方面的数据持久化需求：
1、容器对应的存储卷在进行故障恢复时，会带来卷的挂载和卸载。为了保证整个生产环境的高可用，卷的挂载和卸载一方面需要具有足够的稳定性，同时也需要考虑性能需求，避免应用延迟。
2、存储卷快照管理需求。传统的存储卷快照策略主要从资源角度进行管理，而容器的存储卷往往动态分配而来，快照策略需要与容器应用备份需求保持一致。
3、容量扩容需求：随着容器应用数据的增长，存储卷容量需要考虑扩容的能力，最大程度避免对应用运行的影响。
4、运维管理需求：随着容器有状态应用的增长，对传统存储运维工作也会带来挑战，整体方案需要兼顾运维敏捷和安全。
5、分布式存储需求：银行创新业务的扩展能力通常都是横向扩展的，需要容器云具备横向扩展的能力，需要引入分布式存储架构部署在容器云平台上。

为了能更好的解决大家在容器云持久化上的需求及方案设计下遇到的建设难点，twt社区特意邀请了某大型银行的容器云专家以及smartx的容器持久化专家在线辅导答疑。帮助大家更好的解决容器云场景下更多数据类型的持久化存储建设。以下等的内容一共分这4个部分进行总结： 容器持久化存储建设难点和关注点 、 容器持久化存储的建设方案重点考虑的涉及层面 、 容器持久化技术层面的选择 、交流总结共识部分。

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

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

嘉宾： rechen 云计算架师 , 招商银行
有状态应用的状态可细分指拓扑状态、存储状态。 其中 拓扑状态 指应用的多个实例之间不是对等关系，这些应用实例，必须按照某种顺序启动 。存储状态则是指应用的多个实例分别绑定了不同的存储数据，对于这些应用实例来说。当应用因为某些原因导致了宕机，重启后依旧可以正常的读取到数据。在容器云上部署的有状态应用，其部署需求有：维持稳定且唯一的网络标识，提供稳定持久的存储，提供有序和优雅的部署和伸缩能力，提供有序和自动的更新能力。因此存储设计时，要综合考虑到有状态应用的特征进行设计，譬如在容器云上部署数据库这类有状态应用，和部署日志监控这类有状态应用就有不同的设计维度和优先级。存储产品的选型优先考察稳定、安全、性能和 API 能力。

嘉宾： nawang 产品经理 , SmartX 超融合
存储系统需要能够良好的运行在各种不同服务商提供的公有云环境或私有云环境，能够很好地和其他云原生基础设施配合，例如云原生数据库，使得云原生数据库可以真正的在公有云和私有云都能够得到一致的用户体验。存储系统需要为运维人员提供相同接口和运维方式，即运行在 K8s 中，使用 K8s 的工具进行运维和管理，具备容器化部署、自动运维、声明式接口等特征，降低运维团队的负担。

嘉宾： asdf-asdf 研究学者 , cloudstone
当前有状态应用的容器应用部署，如果有能力应修改应用。使其状态保存在缓存服务器类似 Redis cluster 中，相关日志统一进入 elk ，或者 kafka 完成持久化。这样存储设计相对简单，只要保证 elk 和 redis 的存储容量和访问速度。如果无法修改应用，需要挂载一个持久化卷，来持久化数据。使数据可以在不同节点漂移，需要所有主机对存储的访问权限，这个又会出现存储访问风险。在实际业务场景，把存储分多个区域， 挂载到对应区域的主机，进行区别访问。避免访问风险

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

嘉宾： rechen 云计算架师 , 招商银行
容器云的持久化存储的选型，还是要根据承载的工作负载进行具体分析。譬如在容器云上部署关系型数据库，且数据库的数据是重要的业务系统数据，则选择集中式存储为宜。如果是业务应用系统的日志，或者是配置文件，则建议优先选择分布式存储，在扩展性和成本收益上更佳。

嘉宾： nawang 产品经理 , SmartX 超融合
集中式存储：可以在 Kubernetes 中使用已有的 FC-SAN 或 NAS 。然而，传统存储不可弹性扩展、依赖专有硬件、运维管理相对复杂等特点与云原生所要求的敏捷背道而驰，它们并不是 K8s 的首选。分布式存储：分布式存储天然具有横向扩展能力，在性能和高可用方面远优于集中式存储，非常适合应对大规模虚拟化场景。不过在实际的使用过程中，大部分分布式存储的性能和稳定性都难以达到生产级别的标准，这使得很多运维团队不敢轻易地部署分布式存储产品。

更详细的对比可以参考：云原生时代需要什么样的存储系统。

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

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

嘉宾： rechen 云计算架师 , 招商银行

金融行业企业级容器持久化存储方案，建议从稳定性、安全性维度上，选择商用产品。选择走开源路线的话，则必须要自建研发团队补齐稳定性和安全能力，以及高水平的运维团队，这样综合成本上看，是投入大、风险高且见效慢，不利于金融行业提升业务核心竞争力。

嘉宾： nawang 产品经理 , SmartX 超融合
建议选择商用型存储方案。

商用型存储方案，以 IOMesh 云原生存储产品为例，相较 Ceph 、 GlusterFS 类开源架构的分布式存储，优势有以下几点：

1 ）掌握核心代码，可控性更强。
开源产品的演进由社区主导，厂商无法根据客户需要快速落地功能；出现严重问题时也不能特别快速地响应，往往需要等待社区的修复。 IOMesh 选择自主研发的形式，充分把控产品质量和功能，可以根据众多客户的实际需求迭代产品，也能在出现问题时提供本地研发级别的快速响应，为用户业务运转提供强有力的保证。

2 ）更灵活。
通过元数据服务实现数据副本的精确放置，可以形成更加灵活的副本分配策略，并按照资源进行调整副本分配位置，而不是简单打散；

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

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

嘉宾： nawang 产品经理 , SmartX 超融合

1. 云原生存储系统需要能够良好的运行在各种不同服务商提供的公有云环境或私有云环境，能够很好地和其他云原生基础设施配合，例如云原生数据库，使得云原生数据库可以真正的在公有云和私有云都能够得到一致的用户体验。
2. 云原生存储系统需要为运维人员提供相同接口和运维方式，即运行在 K8s 中，使用 K8s 的工具进行运维和管理，具备容器化部署、自动运维、声明式接口等特征，降低运维团队的负担。

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

嘉宾： nawang 产品经理 , SmartX 超融合
开源产品的演进由社区主导，厂商无法根据客户需要快速落地功能；出现严重问题时也不能特别快速地响应，往往需要等待社区的修复。

而商用型存储方案，尤其是厂商具备自主研发能力的，可以充分把控产品质量和功能，可以根据众多客户的实际需求迭代产品，也能在出现问题时提供本地研发级别的快速响应，为用户业务运转提供强有力的保证。

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

嘉宾： rechen 云计算架师 , 招商银行
需对容器的数据做好分层规划，容器镜像放在镜像仓库中，不必做备份；容器实例存取的数据，如果是存储在分布式文件系统中，则做好分布式文件系统的高可用和备份即可。

嘉宾：强哥之神 容器云架构师及技术经理 , 上汽云计算中心
容器数据备份，首先是明确是哪些数据，是日志还是应用产生的数据，还是应用需要依赖的数据。

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

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

如果是应用依赖的数据，比如中间件数据库等应用，也可以持久化到分布式存储中，但这种情况更多会追求存储性能，就需要用本地卷如 LocalPV 来实现，但本身需要依赖应用自身做好数据的同步，比如 mysql 的主备通过 binlog 同步。

嘉宾： half_life 研发总监 , 上海骥步科技有限公司
容器的数据备份，其实就是有状态应用在 k8s 的备份问题（不包括容器的镜像），个人认为实际上已经不能把容器本身以及应用的数据分开来了。备份的时候，应该把应用以及应用相关的资源，如 configmap ， secret ， pv ， pvc ， service ，以及 pv 里面的数据，一起备份下来，并且拷贝或者上传到第二存储，同主存储隔离开来。

目前国外主流的产品有 kasten 的 K10 ， Portworx PX backup ，以及社区的开源项目 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 项目，可对集群资源备份和恢复。

嘉宾： zhuqibs 软件开发工程师 , Mcd
首先，容器中如果有数据，有三种方式放置， tmp 、 hostpath 和 storageclass
其次，如果要备份容器内的数据，如果使用 tmp 显然不可能，如果是 hostpath ，需要到指定的节点上去备份，但容器环境中， pod 会切换，生产环境不会使用。

所以，生产的容器环境数据要备份，必然容器中的数据是 storageclass ，也就是说，要么是分布式存储，要么是集中存储，而这种存储，通常都是多副本的，多副本一般是无须备份的。

如果，真的一定要备份，请在容器所涉及应用的逻辑层，进行备份比较合适，比如如果是 Elasticsearch ，可以用 reindex ，把索引数据拉到另一个集群。

嘉宾： sabotage 研发工程师 , oxford
设计上需要把容器尽可能做的无状态服务，状态保存在外部公共存储池中或云组件里，这样才能实现容器任意调度，迁移，按需扩容缩容。状态包括内存状态（保存在缓存池），数据库（保存在云数据库），文件（保存在分布式文件系统）

典型如 web 服务的 session 信息，要么存储于公共的 kv 存储里，要么用类似 jwt token 等分布式鉴权，总之需要避免在容器内部保留超过一次交互以外的数据。

容器最大优势是便于迁移缩放，部署灵活，带上数据就失去了这个迁移能力，所以不是说不能存数据，而是从架构层面把有状态服务放容器就是错的

嘉宾： sf7071 云计算研发工程师 , 某大型银行
容器中的数据要持久化，一般会挂载宿主机上的本地存储，或者分布式存储，即使容器销毁了，数据仍然在，新建的容器照样挂在原来的存储就能恢复数据。在容器云上部署数据库，部署架构也要是高可用的集群，集群各节点间应该有数据同步机制。所以，备份容器是没用的，容器是静态的镜像运行起来后的实例，容器里本身不应该存放持久化的数据。

嘉宾： jakeyyu 系统架构师 , 三甲医院
容器备份能不能采用快照技术，如果能够采用快照技术，可以考虑直接备份容器，最方便的。

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

嘉宾：北京不眠夜 产品经理
通过容器平台 CSI 标准接口调用现有存储资源。常见存储有 NAS 、 IP-SAN 、 Ceph 等。通过 PV 、 PVC 完成挂载。

数据备份 / 恢复

容器平台侧，实现对平台数据库、 ETCD 的数据库高可用即可。同时，借助传统备份软件实现数据备份，增加一层保险。

应用软件侧，应用程序有镜像做背书，数据库非容器化，参照传统数据备份方式。如数据库容器化，需要看平台是否提供相应能力。

嘉宾： jakeyyu 系统架构师 , 三甲医院
设置运行容器的镜像进行数据同步，或者采用容器快照技术

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

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

嘉宾： rechen 云计算架师 , 招商银行
这和 NFS 服务器的能力有直接关系，建议选择商用产品，譬如 nexenta 。

嘉宾： nawang 产品经理 , SmartX 超融合
NFS PV 配额的限制需要由 NFS 的服务端来控制，如在服务端限制具体共享卷目录的配额。

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

嘉宾： rechen 云计算架师 , 招商银行
需要综合根据 IAAS 层的存储服务的支持和容器云的应用存储需求而定。

1 ）对于有状态应用的容器应用部署，要考虑其对计算和存储性能的需求，选择兼具高性能、安全 的灵活性的基础架构硬件设备。
2 ）对于容器云有状态应用的数据持久化管理，尽量采用 CSI 插件的方式进行管理，无论是块存储还是 文件存储，都可以通过 CSI 提供的 iSCSI 、 NFS 等方式去使用。
3 ）应用的配置数据存储， 主要是用来管理容器，可以借助现有的存储来实现，主要是一些配置数据和日志记录等管理数据，譬如可以使用 ETCD 和配置中心来存储。
4 ）应用自身的数据存储 , 是应用真正需要保存的数据，需要写入持久化的 Volume 数据卷， 必须确保数据能被不同的节点所访问，且数据存储接口以文件形式会更适应应用访问。
5 ）容器持久化存储一般可以通过两种形式来实现 : 一是本地盘的形 式，优势是简单易用，缺点是难以迁移共享以及伸缩 ; 二是共享存储集群的形式，优势是数据共享， 可以提供多种存储接口，可以弹性伸缩，缺点是架构稍显复杂。

嘉宾： nawang 产品经理 , SmartX 超融合
一般来说 FileSystem 类型的卷更通用，由存储服务来负责管理文件系统，用户只需要读写指定的目录即可；但是如果需要更高的灵活性以及性能，可以采用 Block 类型的卷，在容器中会挂载为一个块设备，用户可以对块设备进行分区、创建文件系统、或是直接读写都是可以的。

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

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

嘉宾： Hsia SA , 某消费金融
三种常见日志收集解决方案
1 ）每个 app 的镜像中都集成日志收集组件：
优点：部署方便， kubernetes 的 yaml 文件无须特别配置，可以为每个 app 自定义日志收集配置
缺点：强耦合，不方便应用和日志收集组件升级和维护且会导致镜像过大

2 ）单独创建一个日志收集组件跟 app 的容器一起运行在同一个 pod 中：
优点：低耦合，扩展性强，方便维护和升级
缺点：需要对 kubernetes 的 yaml 文件进行单独配置，略显繁琐

3 ）将所有的 Pod 的日志都挂载到宿主机上，每台主机上单独起一个日志收集 Pod ：
优点：完全解耦，性能最高，管理起来最方便
缺点：需要统一日志收集规则，目录和输出方式

嘉宾： actor168 研发工程师 , 中国联通软件研究院
可以考虑的方面：
1 ）性能考量
涉及到读写盘、读写网络接口的性能问题，涉及到大量容器的读写时， IO 孰高孰低，是否会因为日志导致整体程序崩溃等。相比而言，本地落盘读写速速度快，但对容器云平台来说，本地落盘容器日志的处理和收集又相对繁琐，如：如何动态搜集日志数据、何时清理本地盘数据？

2 ）数据量考量
如果日志量非常大，因为日志导致的带宽增加性价比会更低。

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

嘉宾： ruanyirong 安全架构师 , xxxx
目前我们内部推荐的方案是采用双日志方案，保存两份日志，可进一步保障日志数据安全，方便后续日志分析和故障定位。一方面容器应用的日志可以输入出到标准输出或文件中，输出到标准输出的日志，可通过 ELK 组合开源工具收集到 ElasticSearch 集群 中供后续查询，如果应用无法输出到标准输出，则使用 sidecar 方式直接发送到 ElasticSearch 集群 ，通过另外的日志服务系统提供日志查询服务；另一方面日志文件持久化到共享存储中，支持通过服务器查看。

嘉宾： JanXC 系统架构师 , nec
建议直接网络发出吧，只是占用网络 io ，可以配置单独的网卡走日志流量，写入到 es 或其他日志存储分析工具中进行分析。如果先落盘，最终还是要采集分析的，对于日志生产端，同时占用网络和存储的 io 。需要注意的是，不管走网络，还是采集落盘在进行分析，都联系与生产读写及网络做分开，特别是高负载的情况。但是网络发出实现上应该比较复杂，增加节点，而且万一有问题，会出现日志丢失的情况。落盘采集简单可靠，方案成熟，要求不是特别好的话，生产环境落盘采集感觉会好一些。

嘉宾： Steven99 软件架构设计师 , steven
依我个人观点，日志直接发出去。但这个方案通常会复杂些。要保证日志发送失败不会导致服务异常。就优先级别来说，前提是保障业务运行。日志可以丢，服务不能受影响。至于选择哪种方式，考虑自身的能力和整体的架构和组件配置。
1 ）落盘是简单的方式，通常不会带来额外影响，除非 IO 有问题
2 ）在业务里面直接发送日志到外部，比如通过消息方式，需要和消息服务器建立连接，在服务内需要引入日志消息发送组件（也就是说需要先封装日志发送 client 组件），连接可能会断开，网络 io 也可能会是瓶颈，等等，所以整体方案会复杂化不过这个方案是考虑整体趋势和融合架构的结果，有效率方面的考虑，日志发送通常也要考虑批量处理等这个方案有个好处是基于实时事件处理的事中处理可以构建起来，所以说是从整体方案来考虑的。
3 ）容器可以直接打印日志到标准输出，从标准输出采集然后发送到日志中心，目前我们采用的是这种方案。这种方案也相对简单不过依然需要注意的问题是，日志信息一定要格式标准化，分级，运行时可调整记录级别。

嘉宾：强哥之神 容器云架构师及技术经理 , 上汽云计算中心
容器日志收集有三种方案：
第一种，在 Node 上部署 logging agent ，将日志文件转发到后端存储里保存起来， 这里的核心就在于 logging agent ，它一般都会以 DaemonSet 的方式运行在节点 上，然后将宿主机上的容器日志目录挂载进去，最后由 logging-agent 把日志转发出去。举个例子，我们可以通过 Fluentd 项目作为宿主机上的 logging-agent ，然后把日志转发到远 端的 ElasticSearch 里保存起来供将来进行检索。在 Node 上部署 logging agent 最大的优点，在于一个节点只需要部署一个 agent ，并且不会对应用和 Pod 有任何侵入性。所以，这个方案，在社区里是最常用的一种。 但是也不难看到，这种方案的不足之处就在于，它要求应用输出的日志，都必须是直接输出到容 器的 stdout 和 stderr 里。

所以， Kubernetes 容器日志方案的第二种，就是对这种特殊情况的一个处理，即 : 当容器的日 志只能输出到某些文件里的时候，我们可以通过一个 sidecar 容器把这些日志文件重新输出到 sidecar 的 stdout 和 stderr 上，这样就能够继续使用第一种方案了。 在这种情况下，你用 kubectl logs 命令是看不到应用的任何日志的。而且最常用的方案一，也是没办法使用的。那么这个时候，我们就可以为这个 Pod 添加两个 sidecar 容器，分别将上述两个日志文件里的内容重新以 stdout 和 stderr 的方式输出出来。 这时候，你就可以通过 kubectl logs 命令查看这两个 sidecar 容器的日志，间接看到应用的日 志内容了。 由于 sidecar 跟主容器之间是共享 Volume 的，所以这里的 sidecar 方案的额外性能损耗并不 高，也就是多占用一点 CPU 和内存罢了。但需要注意的是，这时候，宿主机上实际上会存在两份相同的日志文件 : 一份是应用自己写入 的 ; 另一份则是 sidecar 的 stdout 和 stderr 对应的 JSON 文件。这对磁盘是很大的浪费。所 以说，除非万不得已或者应用容器完全不可能被修改，否则我还是建议你直接使用方案一，或者 直接使用下面的第三种方案。

第三种方案，就是通过一个 sidecar 容器，直接把应用的日志文件发送到远程存储里面去。 也就是相当于把方案一里的 logging agent ，放在了应用 Pod 里。 在这种方案里，你的应用还可以直接把日志输出到固定的文件里而不是 stdout ，你的 logging- agent 还可以使用 fluentd ，后端存储还可以是 ElasticSearch 。只不过， fluentd 的输入源， 变成了应用的日志文件。一般来说，我们会把 fluentd 的输入源配置保存在一个 ConfigMap 里。 Fluentd 容器使用的输入源，就是通过引用这个 ConfigMap 来指定的。 需要注意的是，这种方案虽然部署简单，并且对宿主机非常友好，但是这个 sidecar 容器很可能 会消耗较多的资源，甚至拖垮应用容器。并且，由于日志还是没有输出到 stdout 上，所以你通 过 kubectl logs 是看不到任何日志输出的。

综合对比以上三种方案，我比较建议你将应用日志输出到 stdout 和 stderr ，然后通过在宿主机上部署 logging-agent 的方式来集中处理日志。这种方案不仅管理简单， kubectl logs 也可以用，而且可靠性高，并且宿主机本身，很可能就 自带了 rsyslogd 等非常成熟的日志收集组件来供你使用。除此之外，还有一种方式就是在编写应用的时候，就直接指定好日志的存储后端，在这种方案下， Kubernetes 就完全不必操心容器日志的收集了，这对于本身已经有完善的日志 处理系统的公司来说，是一个非常好的选择。

最后需要指出的是，无论是哪种方案，你都必须要及时将这些日志文件从宿主机上清理掉，或者给日志目录专门挂载一些容量巨大的远程盘。否则，一旦主磁盘分区被打满，整个系统就可能会陷入奔溃状态，这是非常麻烦的。

嘉宾： feb 系统工程师 , lijin
我觉得能直接发就直接发，时效性，性能要求都好很多。另外磁盘占用也少很多。

不能发的话就保存再转发吧，

嘉宾： Macso 员工 , 光大科技有限公司
1 ）对于集群级别的日志采集方案还是选择不落盘采集，避免因为 I/O 影响性能。
2 ）应用级别的日志采集，分情况，能标准输出的也不落盘；只能打日志文件的那就先落盘后再 sidecar 标准输出或者直接转发到后端

4 、企业容器云承载数据库负载或大数据负载时，需要做哪些存储优化？

嘉宾： JanXC 系统架构师 , nec
之前看过不少资料不建议数据库跑在容器平台，理由也都比较充分，但是也有一些公司的确是在容器跑了数据库吗，以 mysql 居多，业务量比较少，没啥问题，业务量一多，性能问题比较明显，这应该主要在网络和存储两方面。就存储来说，建议跑数据库采用全闪。

四、交流总结达成共识

（ 1 ）容器云持久化层存储设计时，要综合考虑到有状态应用的特征进行设计，譬如在容器云上部署数据库这类有状态应用，和部署日志监控这类有状态应用就有不同的设计维度和优先级。存储产品的选型优先考察稳定、安全、性能和 API 能力。

（ 2 ）金融行业企业级容器持久化存储方案，建议从稳定性、安全性维度上，选择商用产品。合适的其他行业的容器持久化的存出方案，也建议选用商用方案。

（ 3 ）从灾备方面考虑首先容器的数据做好分层规划，容器镜像放在镜像仓库中，不必做备份；容器实例存取的数据，如果是存储在分布式文件系统中，则做好分布式文件系统的高可用和备份即可。

（ 4 ） FileSystem 类型的卷更通用，由存储服务来负责管理文件系统，用户只需要读写指定的目录即可；但是如果需要更高的灵活性以及性能，可以采用 Block 类型的卷，在容器中会挂载为一个块设备，用户可以对块设备进行分区、创建文件系统、或是直接读写都是可以的。

（ 5 ）对于集群级别的日志采集方案还是选择不落盘采集，避免因为 I/O 影响性能。对于应用级别的日志采集，分情况，能标准输出的也不落盘；只能打日志文件的那就先落盘后再 sidecar 标准输出或者直接转发到后端