信创云环境下，云原生技术如何与存储相结合？|《迈向YB数据时代》
信创云环境下，云原生技术如何与存储相结合？|《迈向YB数据时代》
talkwithtrend
talkwithtrend.com社区（即twt社区）官方公众号，持续发布优秀社区原创内容。内容深度服务企业内各方向的架构师、运维主管、开发和运维工程师等IT专业岗位人群，让您时刻和国内企业IT同行保持信息同步。
以容器为代表的云原生技术体系已进入大中型企业重要关键应用，日志、缓存、数据库等有状态应用在容器环境不可避免要解决持久化数据存储的问题。本议题围绕如何满足云原生应用数据存储需求来展开讨论。
本期为大家带来 《迈向YB数据时代》 2023年夏季刊“最佳实践 ”栏目 中的 议题三 ：
信创云环境下，云原生技术如何与存储相结合？
【栏目主编】张鹏 某金融科技公司高级技术主管： 本议题由江西银行存储工程师程宗憬、银河证券资深架构师汪照辉、邮政储蓄银行系统架构师董爱军发表针对议题下关键点的主张，几位专家的主张在某农商银行架构师胡海光、某金融公司架构师刘艳春及我本人等多位专家的复议后，形成了一定的共识，希望可以对同行有一定的参考。
程宗憬 江西银行存储工程师 ：
在存储服务演进过程中，每一种业务类型、新技术方向都会对存储的架构、性能、可用性、稳定性等提出新的要求。现在已到云原生技术日新月异的时候，对于存储服务的选择也有了新的要求与挑战。
随着数字化时代的到来，云原生技术正以令人惊叹的速度塑造着软件开发和部署的未来。在这个快速变化的技术环境中，云原生已经成为创新的引擎，为企业提供了更高效、敏捷和弹性的方式来构建、交付和管理应用程序。而存储是支撑业务，数据保存的底座，是信息系统中的重要组成部分，也是所有应用得以运行的基础，其重要性不言而喻。在存储服务演进过程中，每一种业务类型、新技术方向都会对存储的架构、性能、可用性、稳定性等提出新的要求。现在已到云原生技术日新月异的时候，对于存储服务的选择也有了新的要求与挑战。
一、云原生特性
从官方的定义可以看出云原生是一种软件开发和部署方法论，旨在最大程度地利用云计算的优势，以更快、更敏捷、更可靠的方式构建和运行应用程序。为了满足应用程序在云环境中的数据管理需求，以实现更高效、弹性和可扩展的存储解决方案，就要实现将云原生方法与存储技术相结合。
（1）轻量、快捷稳定的基础环境
在云原生环境中，支撑基础设施通常是容器技术。容器生命周期极短，大部分是以秒或分钟为单位，占用的资源也比虚拟化小得多，所以容器的最大特点就是轻和快。而正是因为容器有轻和快的特点，在实践中通常不会在容器中安装或更新应用，而是更新更为持久化的镜像，通过编排系统下载新镜像并启动相应的容器，并将旧的容器删除。这种只更新镜像而不改变容器运行时的模式称为不变稳定的基础设施。从不变的基础设施就能看出，云原生的运营与传统虚拟机运营方式截然不同。
（2）服务的弹性扩展
云原生系统具有弹性扩展的能力，可以根据需求自动调整资源，以适应变化的工作负载。这种能力使系统能够在需求高峰时保持稳定性和性能。云原生的焦点是业务，而非基础设施，而业务的最核心之处是业务管理和控制，如服务暴露、负载均衡、应用更新、应用扩容、灰度发布等。服务编排提供了分布式的计算、存储和网络资源管理功能，可以按需、弹性地控制服务的位置、容量、版本，监控并保证业务的可访问性。
（3）持续交付和持续部署
云原生持续交付和持续部署是云原生开发方法中至关重要的环节，它们旨在实现快速、可靠和自动化的应用程序交付和部署。持续交付和持续部署是一组将软件开发和IT运营相结合的实践，目标在于缩短软件开发周期，并提供高质量软件的持续交付。
二、云原生环境存储的类型
云原生存储技术类型涵盖了在云原生应用开发和部署过程中使用的不同存储解决方案。这些技术类型旨在满足云原生应用的动态性、可扩展性和持久性数据管理需求。
1. 持久化存储
云原生持久化存储是云原生应用开发中的一个关键概念，旨在为容器化的应用程序提供持久性数据存储解决方案。在云原生环境中，应用程序的组件和服务可能会频繁地创建、销毁和迁移，因此需要一种能够保持数据的持久性和可访问性的存储机制。
2. 数据库存储
数据库系统用于结构化数据的存储和管理，适用于各种不同的应用场景。关系型数据库（如MySQL）和NoSQL数据库是常见的数据库系统。
3. 内存存储
内存存储将数据存储在内存中，提供了极快的读写速度，适用于需要低延迟和高吞吐量的应用，如缓存和实时数据处理。主要包括缓存数据，如Redis、Memcached等。
4. 持续集成和交付存储
是为支持云原生应用程序的自动化构建、测试和部署流程而设计的存储技术。它旨在帮助开发团队实现快速、可靠的应用程序交付，同时确保数据的安全性和一致性。主要用于存储容器的镜像仓库，例如Docker Hub、Container Registry等。
5. 日志存储
日志聚合平台用于收集、存储和分析应用程序和系统生成的日志数据。例如ELKStack（Elasticsearch、Logstash、Kibana）、Fluentd、Splunk等，用于收集、存储和分析应用程序日志。
6. 配置存储
主要是键值存储，如etcd、Consul等，用于存储和管理集群、平台或者应用程序配置相关信息。键值存储是一种简单的数据存储方式，通过键值对存储和检索数据。它适用于需要快速访问和查询数据的应用，如缓存和元数据存储。以上总结如表。
表 各类存储特点及使用场景
三、云原生存储部署的业务流程实践
1. 确定应用程序需求
确定应用程序的需求是一个关键的步骤，它有助于确保所选的存储技术能够满足应用程序的性能、可用性和可靠性要求。首先需要了解应用程序处理的数据类型（如结构化、非结构化、大数据等）以及数据的访问模式（读取、写入、随机、顺序）；确定应用程序的性能需求，包括延迟、吞吐量和IOPS（每秒输入/输出操作数），不同的存储技术在性能方面可能有所不同，您需要选择与应用程序性能需求相匹配的存储解决方案；估算应用程序所需的存储容量，考虑到数据的增长和变化。确保所选存储技术具备足够的容量和可扩展性。
2. 选择适当的存储技术
确定适合的云原生存储方案是云原生存储部署中的重要一步，它需要综合考虑应用程序的需求、性能要求、数据管理策略和预算等因素。在了解应用程序的需求，包括数据类型、访问模式、性能需求、容量需求、数据保护等需求的前提下，选择合适的存储类型，如块存储、文件存储、对象存储、键值存储等。不同存储类型适用于不同的用例，确保选择与应用需求相匹配的类型。当然选择对应的存储技术时，可以基于特定的云平台，包括常用的Kubernetes集群等。在规划时，考虑存储方案的可扩展性，以适应数据的增长和变化，并确保所选存储方案能够与您的云原生环境和应用程序无缝集成，比如考虑存储方案是否与容器编排平台（如Kubernetes）、CI/CD工具和其他组件兼容。
3. 集成容器编排平台
在云原生存储部署中，集成容器编排平台（如Kubernetes）是非常重要的，因为容器编排平台可以帮助管理和调度容器化应用程序以及它们的相关资源，包括存储。Kubernetes平台支持各种存储的插件，允许将不同类型的存储技术集成到容器环境中，实际规划中需要根据存储需求，选择适合的存储插件；根据选择的插件，定义及创建Kubernetes存储类、持久卷（Persistent Volume）等资源，并将存储插件的配置信息添加到Kubernetes集群中。
4. 定义持久卷规范
定义持久卷规范（Persistent Volume Specification）是一个重要的步骤，它明确定义应用程序所需的持久卷资源。持久卷规范通常在容器编排平台（如Kubernetes）中使用，以便在应用程序部署时分配和管理持久性存储资源。持久卷规范包含了存储类的选择，首先就需要选择适合应用程序需求的存储类；执行访问模式，如读写一致（ReadWriteOnce）、只读多次（ReadOnlyMany）和读写多次（ReadWriteMany）。根据应用程序的需求，选择适当的访问模式；选择合适的存储类型，包括位置和配置，如果是本地存储，需要指定本地存储的路径；对于持久卷规范的变化和更新，同时建议进行版本控制，并及时更新文档，确保使用和管理持久卷资源的策略最新。
通过定义清晰和准确的持久卷规范，企业可以在容器编排平台中有效地管理和调度持久性存储资源，以支持云原生应用程序的持久性数据需求。
5. 实现自动化及动态管理
自动化和动态管理是关键的概念，它们有助于实现存储资源的灵活分配、自动伸缩和高效利用。基于负载或性能指标，可以实现存储资源的自动伸缩。根据应用程序的需求，自动调整存储容量、IOPS等，以确保性能和可用性；配置监控和警报系统，自动检测存储故障，并根据预设的策略自动执行故障恢复操作；将存储自动化流程整合到持续集成和持续交付（CI/CD）流程中。确保存储资源能够与应用程序的生命周期保持一致。通过实现自动化和动态管理，可以确保存储资源在不同情况下能够自动适应变化，提高存储资源的利用效率，减少手动操作的工作量，并提供可靠的数据管理和存储服务。
6. 设计数据保护策略
设计数据保护策略在云原生存储部署中至关重要，它可以确保企业的数据在存储过程中得到充分的保护，防止数据丢失和故障。确定数据备份的频率和方法，以及在发生故障时的数据恢复过程。定义备份存储的位置和保留期限，以及如何恢复数据到原始状态；对于支持快照功能的存储技术，定期创建数据快照，以便在需要时能够回滚到先前的状态。确保定期测试快照的可用性和恢复性；如果应用程序涉及多个数据中心，考虑将数据备份到不同的地点，以实现业务的冗余和容灾能力。对于异地灾备的需求，设计跨地理位置的容灾方案，确保数据在主生产中心发生故障时能够在灾备端进行恢复。
一个健全的数据保护策略可以帮助您预防数据损失，降低风险，并确保数据在云原生环境中得到充分的保护。
7. 实施安全措施
云原生存储部署中，实施安全措施是至关重要的，可以帮助保护企业的存储资源和数据免受潜在的安全威胁和风险。强制实施访问控制机制，确保只有经过授权的用户和应用程序能够访问存储资源；将不同应用程序的数据隔离开，防止跨应用程序的数据泄漏和干扰。使用虚拟化和容器隔离技术，确保数据的隔离性；确保容器本身的安全，借鉴容器安全的最佳实践，使用容器安全工具，减少容器漏洞的风险；定期检查存储系统的漏洞，及时应用安全补丁和更新，以防止已知的安全漏洞被利用。
8. 持续优化
持续优化是确保存储资源高效利用、性能优越以及数据安全的关键。通过不断优化，可以最大程度地提高存储环境的可靠性和性能，一般来说需要做到以下几个方面：定期监控存储资源的性能，包括吞吐量、延迟和IOPS。根据监控数据进行性能调整，确保存储资源能够满足应用程序的需求；持续监控存储资源的容量使用情况，及时进行容量规划和扩展。避免存储资源耗尽，影响应用程序的运行；根据负载情况和性能指标，实现存储资源的自动扩展。配置自动伸缩机制，根据需要自动调整存储容量和性能；根据数据的访问频率和重要性，将数据划分为不同层次，选择合适的存储技术和存储类别。将热数据存储在高性能存储中，将冷数据存储在低成本存储中；使用数据压缩和去重技术，减少存储资源的占用。这可以降低存储成本并提高存储效率；定期评估和调整存储策略，根据应用程序需求进行优化。例如，调整数据备份频率、快照保留期限等；针对性能瓶颈，进行存储系统的调优。优化存储配置、调整缓存策略和调整队列深度，提高性能；在有多个存储节点或副本时，实现负载均衡，确保数据均匀分布和访问；在容器编排平台中优化存储资源的编排方式，确保应用程序对存储资源的访问效率。
四、新的挑战与经验
基于以上云原生特征及流程实践的讨论，我们可以知道云原生计算是一种面向云环境设计和构建应用程序的方法，它强调容器化、微服务、自动化和弹性等原则。因此为满足这些特性，对底层存储的逻辑及实现带来了新的挑战。
挑战的出现是基于新技术特征和需求而出现的，总的来说主要包括：
（1）复杂的管理，自动化管理是云原生环境的基本要求。存储系统需要提供自动备份、快照、数据迁移和故障恢复等管理功能，以减少人工管理的工作量。
（2）兼容性问题，单一环境多云的管理，要求云环境需要跨云实现兼容，就要求存储能够实现不同云环境的无缝运行。
（3）性能要求，需要以高性能低延迟的性能满足海量云原生应用的运行，提供实时性的存储服务。
（4）持久性存储，虽然容器的数据是短暂的，但许多应用程序需要持久性的数据存储。确保数据持久性和可靠性是一个挑战，需要采用适当的存储解决方案和策略。
（5）容器化的部署，存储系统需要容器化，以便与容器化应用程序一起工作。这要求存储可以以容器的方式部署和管理，并与Kubernetes集群集成。
为应对这些挑战，通常在实施过程中：
（1）考虑将存储纳入云原生架构的设计中。主要包括如何将存储容器化、如何使用存储编排工具来管理存储资源，以及如何实现存储的自动化管理，实现云原生存储跨云的兼容性。
（2）在选择存储解决方案时，考虑应用程序的特点和需求，选择合适类型的存储，比如高性能计算场景中，同时启动数千Pod情况下可能出现性能下降的问题，则可以考虑使用分布式的多文件系统分散读写压力提高性能。
（3）制定有效的备份和恢复策略，确保数据的安全性和可恢复性，可利用云原生环境中提供的工具实现。这点主要针对运维层面，实现块存储随容器迁移的稳定性和可发现性。
总之，云原生存储是云原生应用的基石，并不能看成某一组件对另一组件的单方面适配，而是应用与底层基础架构的互相融合和调整。构建出容错性兼容性好，性能强，具备持久化特性的云原生底座，是云原生存储实施的目标，这个目标的实现可以大大提高系统开发迭代的效率，也大大提高资源的利用率。
信创云原生的关键在于信创云的建设和基于信创云支撑云原生应用的体系建设，是一项并不简单的体系工程。
云原生是一种思想方法论，是借助云计算的思想和特性实现应用的云端构建、部署、运行等。信创云原生是采用国产化的CPU、存储、网络设备、操作系统、中间件等构建的信创云之上实现云原生应用的构建、部署、运行等，这些云原生应用构建、部署、运行、管理等的环境也是国产化的。虽然云原生的概念、理念、思想和技术等基本上都是自国外，并且云原生体系中的微服务、容器、DevOps、ServiceMesh等也是源于国外的开源项目，不过由于其开源开放性，不涉及硬件设施，因此信创体系下，把云原生的这些思想和技术应用适配到信创环境，就可以实现信创云原生。不过在信创容器运行时、服务治理、存储管理、API网关等技术方面还是需要持续努力的。
一、信创云原生是体系工程
信创云原生是在信创云环境下运用云原生的理念、技术、思想、方法等来实现信创云上的云原生应用研发、部署、测试、运行、运维、运营，实现信创云原生应用的弹性和可扩展性、敏捷性等。信创云原生应用的构建和运行离不开信创云的建设。信创云建设方案是一项复杂的系统性工程，不是简单的局部国产化替代，而是从CPU/GPU芯片、存储、网络到信创操作系统、中间件等，以及支撑云原生应用的研发平台、测试平台、部署运行运维平台和工具等，都需要一个拥有自主技术，且经过国内多业务场景的大规模验证和实践的技术体系。因此，信创云原生的关键在于信创云的建设和基于信创云支撑云原生应用的体系建设，是一项并不简单的体系工程。不过目前国内云原生方案依然采用的是开源的技术和组件，如SpringCloud、Docker、Kubernetes、Istio等，信创云通过一云多芯等方案支撑不同技术路线的系统，封装异构细节，从而可以实现信创云原生的低成本迁移，甚至无缝迁移。
二、信创云原生和存储的结合
由于云原生容器有一旦被删除其在运行时容器内部产生的所有文件数据也会随着容器销毁被清理掉的特点，所以Docker提供了逻辑存储卷Volume方式将容器产生的数据持久化到Volume卷上保存下来。作为容器管理和调度框架Kubernetes提供了多种存储卷Volume管理方式支持数据持久化，如本地存储、Static Volume、StorageClass、CSI（Container Storage Interface，容器存储接口）插件方式等。
存储的类型很多，比如块存储、文件存储、对象存储等，每种存储又有多种的协议类型、接口类型、存储架构、存储技术等，所以存储细分非常庞杂。在云原生容器和Kubernetes中，可使用支持的各种类型的Volume来完成数据的持久化，比如本地存储（emptyDir、hostPath）、网络存储（如NFS）、对象存储（Ceph、GlusterFS）等。Kubernetes还允许其他类型的外部服务以如CSI插件等方式接入到Kubernetes系统中。
信创云原生和存储的结合往往意味着存储的选型。不同业务对存储的读写速度、并发性能等的需求是不一样的，所以通常需要基于业务的功能、性能要求选择信创存储设备，同时考虑是否满足信创合规要求等。
从业务角度通常考虑功能和性能需求两个方面。不同业务对存储的需求是不一样的，比如说Jenkins容器可以使用本地存储，容器云平台上业务传输应用文件、日志等可以使用NAS存储卷，音频视频则适合选用对象存储等。还有需要考虑业务对存储性能的要求。我们曾经有个信创集群连接的存储性能比较差，导致整个集群性能很差，etcd健康检查服务都经常失败，不得不更换存储。另外需要考虑合规性、安全性等一些要求。很多业务数据是需要备份的，从合规性和安全性等方面，往往采用两地三中心等模式，云原生Kubernetes集群通常也需要部署于不同安全域，实现集群之间的互备或双活高可用等。另外，云原生平台本身的一些数据和组件也需要进行灾备，以满足等保、安全等要求。
三、存储和云原生容器的结合方式
云原生场景中，Kubernetes提供了本地存储、静态卷和动态存储类StorageClass以及插件的方式来使用存储。
1. 本地存储方式
本地存储方式是指将容器运行时产生的数据存储在其运行节点的本地存储介质上。一般情况下容器云平台不用本地存储方式，因为使用本地存储会限制pod的资源调度。如果简单用Docker在本地启动和运行一些服务，比如说Jenkins。数据库等，可以使用本地存储的方式。它通常用于需要快速访问数据或者需要高性能存储的场景，使用本地存储性能通常要好于NAS等网络存储。
Kubernetes提供了多种本地存储方式，包括EmptyDir、HostPath和Local Persistent Volume等。EmptyDir是Kubernetes自带的，它创建一个空目录，作为容器内部的存储。HostPath允许Pod将节点上的文件系统挂载到容器内部，Local Persistent Volume则是使用本地存储介质作为持久化存储，允许Pod挂载本地存储介质作为卷。
2. 静态存储方式
在静态模式下，企业内的各种类型的存储、存储资源池等由存储管理员来进行维护和运营（属于基础设施资源层），为云原生容器云平台（PaaS层）等提供存储资源服务。云原生容器云平台通过平台管理员为每个集群配置存储连接信息。容器云平台是一个存储资源消费方，同时需要为用户提供存储的配置管理和PV、PVC、存储资源使用情况、PV使用情况等的查询服务能力。当用户创建的Pod申请PVC时，PVC绑定已创建的PV。由于需要提前创建好PV，如果由平台管理员或平台集群管理员来维护PV，则需要不断跟租户用户进行交互，比较繁琐，因此可以将PV创建、删除和维护的权限交给租户，平台可以管理和限制租户的最大存储资源使用量，避免浪费；或者也可以用虚拟计费等方式来优化资源分配占用和使用，以提升资源的使用率。
容器云平台的定位会影响存储的使用方式。如果容器云是以容器为中心进行管理（侧重于IaaS层），则关注的是基础设施容器，而不是容器中运行的业务服务或应用。如果将容器云台作为容器化的PaaS平台（PaaS层）实现以应用为中心进行管理，则应用的管理和治理、API、日志、监控、链路、存储、网络等将都围绕应用而展开，容器只是个运行时引擎工具（可被无感替换）。这样就将业务数据和存储直接关联起来，根据业务需求进行存储选型，如图1所示。
图1 静态持久化存储资源PV供应模式
3. 动态存储StorageClass方式
在大规模Kubernetes集群中，可能会生成成百上千的PVC，需要创建成百上千个PV，如果由人工来维护，效率可能非常低。容器的动态变化也可能不断创建、删除PVC，人工的响应往往难以满足需求。 Kubernetes提供了一套自动创建PV的机制，也就是Dynamic Provisioning，核心在于StorageClass对象。StorageClass对象包含PV定义和创建PV的存储制备器，根据用户提交的P VC，找到对应的StorgaeClass，使用该StorageClass声明的存储插件来创建PV，Pod通过PVC动态绑定PV。要使用StorageClass，就需要安装对应的自动配置程序，比如我们使用NAS存储，后端使用的是NFS，就需要安装一个NFS-client的自动配置程序Provisioner，这个程序使用后端的NFS服务器来自动创建PV。通过StorageClass定义，可以将存储资源定义为某种类型的资源，比如高性能存储、通用存储、分布式GlusterFS、Ceph等，用户根据StorageClass的描述可以非常直观的知道各种存储资源的具体特性，就可以根据业务应用需求申请合适的存储资源。
使用StorageClass主要在一些场景中在运行时动态绑定存储资源，比如说某个容器进程在运行时需要启动其他容器进程并需要绑定PV。这种场景下，无法通过手工来创建PV，然后由PVC绑定，就需要使用定义好的StorageClass，来动态创建PV，如图2所示。
4. CSI存储插件
容器存储接口（Container Storage Interface，简称CSI）是一种行业标准，用将块和文件存储暴露给Kubernetes等容器管理调度系统。CSI插件存储架构由两部分组成:External Components和Custom Components。External Components是从Kubernetes中的存储体系中剥离出来的存储管理功能，与Custom Components即CSI存储插件交互。CSI存储插件通常由存储厂商来实现并提供下载支持。有些旧的存储可能不支持CSI插件。如果想使用CSI时，需要确认存储是否支持CSI，是否能提供相应的CSI 驱动和插件。在使用CSI插件时，每个集群需要部署一个CSI Controller，包含provisioner、attacher和csi插件，以StatefulSet或deployment方式部署，集群中每个节点部署一个CSI node，以DaemonSet方式部署，包含Driver registrar和CSI插件。
比如说华为存储提供的CSI接口中，有csi node和csi controller组件，node以daemonset方式部署在每个K8s节点上，controller以deployment部署。其中Node Pod中有3个容器/组件，Controller Pod中有7个容器/组件。
图3 csi node和csi controller组件
5. 备份
备份可能是信创云原生平台使用存储最多的场景。需要备份的数据有很多，比如说镜像备份、容器备份、日志备份、业务文件备份、数据库备份、虚拟机备份等。我们也曾经发生过不小心删除了某个应用的情况，应用下有多个服务，意识到删错服务后也是惊出一身冷汗，好在快速恢复了过来。如果没有备份，只能重新部署，就可能需要花费更多的时间。
目前使用的备份软件主要还是针对Docker容器做备份，对集群管理组件目前还不支持直接备份。对于部署在Linux环境的api-server、controlmanager、scheduler之类的组件，备份软件可以通过文件备份的方式备份相应的配置文件，或者对节点虚机进行备份的方式进行保护。不过备份并不是做到实时备份，如果出现意外，可能会面临着一些数据的丢失。备份恢复只能恢复到最新的备份时点，备份间隔越长，丢失的数据就可能越多，选择合适的备份间隔也是一项重要的事情。
厂商提供的云原生容器云平台备份主要有两种方式，基于CSI的快照备份和Non-CSI的备份。对于支持CSI的容器，备份工具调用CSI进行快照，对指定的容器进行快照，然后再把快照数据备份到备份存储，数据恢复的时候可以直接从快照恢复，也可以从备份存储进行恢复；对于不支持CSI的容器，备份工具会采用“导出应用文件到持久卷”+“文件备份”的方式，把需要备份的数据备份到备份存储，数据恢复的时候把备份文件恢复到容器所在的持久卷上。
备份还是主要以保护数据为主。为保障数据安全和完整性，还需要结合其他手段，比如说断点重发等。
6. 存储容量评估
容量规划是云原生体系重要的内容之一。存储容量评估通常分几个层次，一是节点的存储需求，二是备份需求。
基于CPU、内存容量和可承载的Pod数量及每个Pod的平均存储需求量。节点上的存储使用量通常用于服务日志，有些服务在打开debug时可能会短时间产生大量的日志，从而把节点空间占满。这种情况就不能无限扩展存储资源，而是需要限制日志文件的数量和每个文件的大小，使一个服务的总日志占用量有个最大值。
备份容量评估通常是按“实际有效数据量”和“重删后的数据量”来计算的。比如说：300TB分配空间，实际有效数据是100TB，100TB经过重删后（重删率按80%计算），实际落盘的备份容量大概是20TB。虽然有重删技术可以减少后端存储空间，但是考虑到备份数据都要保留一段时间，需要保留多个备份副本，所以，一般建议至少要准备2倍的存储容量，备份源端要和备份存储容量的空间保持一致。比如有1T的源端备份需求，需要采购2T备份容量，也就是1:2。
四、容器云平台对 NAS 存储支持设计实践
在当前需求和Kubernetes对NAS存储有限支持的情况下，我们在想是否可以找到一种简单的方式来更好的在容器云平台支持NAS存储，而不用带来巨大的定制化开发工作，同时又保持和以Kubernetes为基础的容器调度管理平台的松耦合。我们和UCloud等多位存储专家讨论过不同的实现方案，但也没有什么好的共识。不过对我们来说，首先要考虑先支持业务需求，因此我们考虑先用下面的思路实现。
1．存储管理的两个视角：平台管理员视角和租户视角。平台管理员维护容器云平台的所有存储资源，比如Mount存储到平台，分配一块存储给租户，回收分配给租户的资源等。租户只是使用分配的资源。租户可以申请多块存储资源，一旦申请成功（平台管理员分配完成），租户就可以在自己的存储管理界面查看到自己的存储资源列表。
对分布式存储比如Ceph等，这些需求的实现可能相对简单，不过对于NAS存储，可能无法通过调用NAS存储的接口实现，而且NAS存储种类、厂商众多，实现对不同厂商、不同种类的支持也不太现实。所以我们考虑在存储之上通过文件目录结构来实现，不管什么存储，只要支持文件结构，就可以通过这种软的类似插件的方式进行管控，虽然不完美，但目前来说可能是一种比较简单的方式。
2．平台管理员向NAS存储管理员申请一大块容器云平台使用的存储。比如说500G。在资源整合之前，通常NAS存储会有专人负责管理，容器云平台也是独立的，比如我们存储资源池、虚拟机、容器等彼此独立但又相互联系，都作为基础设施资源。
3．平台管理员拿到NAS存储之后需要根据申请分配给租户。比如租户A申请100G的存储空间，租户B需要20G的存储空间。这里有两种实现方式。第一种是在NAS存储上建立“文件夹A”和“文件夹B”，然后分别mount这两个文件夹给租户A和租户B。第二种方式是整块存储mount到容器云平台，然后直接分配给租户一个子文件夹。
存储卷大小管理需要借助平台保存这些存储卷的信息。不管这些信息是在文件、数据库或etcd中，需要持久化保存。同时要监控文件夹的大小变化，到达存储分配的最大值时禁止继续写入（当然也可以实现存储自动扩展能力），并及时在资源不足时提醒。这可能需要一个进程来完成这项任务。
4．在租户的存储管理界面，列出该租户所有的存储卷信息，包括卷名称（或文件夹名）、容量、使用量、详情（存储的文件目录信息）等。
租户不能通过终端命令行访问这些信息和其他租户的文件，屏蔽租户对宿主机命令行访问能力，只提供租户管理界面存储卷上的文件目录结构访问权限。
5．存储文件的管理也可以借助操作系统用户、组的管理能力。也可不考虑那么复杂，只实现文件目录结构管理，屏蔽终端命令行，做到相对的安全，这样也就只是实现对文件的管理，与具体的存储类型没有关系，但可以满足目前大部分采用容器云平台为不是分布式存储或对分布式存储需求不大的仅使用NAS存储的客户的需求。
6．租户可以申请共享存储卷（共享目录），然后共享给其他租户，这些租户都可以访问共享存储，读写其中的文件，共享卷通过卷标签标识。
这种思路秉承我们容器云平台“三视角四层次一回环”的设计思想，各组件之间尽可能的松耦合，同时简化一些繁琐的设计，尝试采用简单的方法来满足需求。实际的实现过程中也许还需要做一些调整，不过在容器云平台更好支持NAS存储，更好地提供存储服务，这可能是一种比较简单快捷的实现方法。
四、总结
董爱军 中国邮政储蓄银行系统架构师：
随着云计算技术的发展，云原生部署逐渐成为企业级应用的首选架构。Kubernetes作为云原生技术的代表，提供了一整套完整的容器编排和管理的解决方案。在云原生部署中，存储是不可或缺的一部分，它直接关系到应用的性能和稳定性。
随着云计算技术的发展，越来越多的应用程序被部署到云环境中。云原生（Cloud Native）是一种在云环境中设计和部署应用程序的理念和技术体系，它充分利用了云的弹性、可伸缩性、高可用性等优势，使得应用程序能够更好地适应于云环境。容器技术是云原生技术的重要组成部分，其中Kubernetes是最为流行的容器编排平台之一。在云原生部署中，存储是不可或缺的组成部分，它可以为应用程序提供数据存储和备份等功能。本文将阐述如何在云环境中使用Kubernetes容器进行云原生部署，并探讨如何与存储相结合。我们将介绍云原生上部署的规范、流程和步骤，并分享一些最佳实践。
一、存储在云原生部署中的重要性和挑战
在云原生部署中，存储是一个关键的组成部分。应用程序需要持久化存储来保存数据，并且需要高效的存储访问。同时，存储的可靠性和性能也对应用程序的稳定性和响应性有重要影响。然而，在云原生环境中，存储的管理和配置面临一些挑战，如数据持久性、数据一致性和存储资源的动态调度等。
二、Kubernetes 部署流程
1. 环境搭建
首先需要准备一台或多台虚拟机，配置网络并安装Kubernetes集群。这里可以使用Kubernetes的官方安装工具kubeadm来进行简化部署。
2. 容器管理
在Kubernetes中，应用被打包成容器镜像，然后通过Pod进行运行和管理。我们可以编写YAML文件来定义Pod的配置，包括镜像、资源、端口等信息。然后使用kubectl命令行工具创建和启动Pod。
3. 资源调度
Kubernetes通过Controller和Scheduler对Pod进行管理和调度。Controller负责监视Pod的状态并根据需要创建或删除Pod，而Scheduler则负责在集群中调度Pod的运行。通过合理配置Controller和Scheduler，可以实现资源的合理分配和应用的负载均衡。
三、Kubernetes 容器与存储的整合
1. 本地盘
Kubernetes 支持用户直接将本地盘插到服务器上作为存储设备。由于磁盘和应用系统中间的 I/O 路径最短，本地磁盘可以提供最佳的性能。同时 RAID 提供了一定程度的可靠性的保证，可以避免因单个磁盘故障而导致的数据丢失。因此，目前有大量用户采用这种方式为有状态的应用提供存储服务。
但同时，本地磁盘方案也在可用性和扩容方面存在着巨大的缺陷：
1. 本地磁盘无法提供节点级别的高可用，当物理节点发生故障时，应用无法被恢复到其他节点。如果业务系统有节点级高可用的要求，则必须由业务系统自己实现数据层面的高可用，这极大地增加了业务系统的复杂度。2. 本地磁盘也无法满足 Kubernetes 环境下的业务敏捷性需求：业务使用的存储空间受限于本地磁盘的大小，达到磁盘空间的上限后，增加磁盘的操作步骤复杂，要想使用新增的硬盘空间，必须手工修改 Pod 中的配置，难以实现敏捷的平滑扩容。此外，要想对物理节点内的硬盘实现高可用，就需要部署 RAID，这也是相当费时、费力、费钱的方案，难以实现在短时间内为大量的应用系统配置足够的存储容量。
由于以上的缺陷，本地磁盘的方案只适合在业务容器化的初期阶段进行小规模试用，或者作为较低重要性的数据存储使用，难以在大规模生产场景下被广泛使用。并不是云原生存储的范围之内。
另一种方式是通过容器存储接口（CSI）将 Kubernetes 平台与底层存储基础设施连接起来，从而允许 Kubernetes 动态调配和配置存储、实现存储操作自动化。按照为虚拟化环境设计和为Kubernetes环境设计，这种外接存储方案进一步划分为商用存储和 Kubernetes 原生存储两个类型。
广义上说CSI都属于云原生存储的范畴内。
2. CSI 外接商用存储
商用存储既包括软件定义式存储（如分布式存储），也包括传统的集中式存储。与专为Kubernetes 环境而设计的 Kubernetes 原生存储不同，商用存储通常情况下主要为裸金属和虚拟化环境服务。
外接集中式存储提供了可远程访问共享存储的能力。和本地磁盘的方案相比，集中式存储解决了应用系统高可用的问题，当业务 Pod所在的服务器发生故障时，可以通过共享存储在其他节点上把应用拉起来，很多基于集中式存储的商用存储方案也提供快照、克隆、容灾等高级功能。此外，由于数据集中存储，也一定程度解决了本地存储对磁盘空间浪费的问题。
但是：
1. 当面临大量业务并发访问时，存储控制器则成为了性能瓶颈。如果想要满足大量业务对性能需求，需要采用多套集中式存储系统，存储系统的管理成本也会急剧上升。
2. 有碍于盘柜形式，集中式存储扩展能力较差，运维工作量较大，也难以应对短时间内大量 Volume 的并发创建和销毁需求，缺少云原生敏捷性。
外接分布式存储，通过将数据分散存储在网络上的多台独立设备上，分布式存储具有优秀的横向扩展能力和敏捷性，在对接基于分布式计算架构的云原生应用时，性能和高可用方面也远优于集中式存储。不过，市面上可用于Kubernetes 的分布式存储方案鱼龙混杂，一些产品仅基于开源技术简单包装，其性能、稳定性以及对 Kubernetes 环境的支持能力都难以达到生产级别的标准。
3. Kubernetes原生存储
Kubernetes 原生存储是专为支持容器而构建的存储方案。这种存储与 Kubernetes 的集成程度更深，具有容器级别的数据服务粒度和自动化存储资源运维能力，也因此能够为Kubernetes 上的容器应用提供灵活扩展能力与自动化运维能力。
可以选择 Kubernetes 自带的存储方案，如EmptyDir、HostPath、Local、NFS、GlusterFS等，也可以选择外部存储方案，如 Ceph、GlusterFS、Rook 等，如图3所示。
图3 Kubernetes云原生各类存储对比图
四、 结合规范策略
1. 评估存储资源
根据应用程序的需求，为Kubernetes集群分配足够的存储资源，如存储节点、存储卷和存储类等。
存储节点：Kubernetes集群中的节点负责存储容器的数据。确保节点具有足够的存储容量和性能，以满足应用程序的需求。
存储卷：Kubernetes中的Pod可以使用存储卷来访问外部存储系统。根据应用程序的需求，选择合适的存储卷类型，如NFS、GlusterFS、Ceph等。
存储类：Kubernetes提供了一组存储类，可以自动管理存储卷的配置和生命周期。选择合适的存储类可以简化存储管理，并提高应用程序的性能和可用性。
持久卷和持久卷控制器：持久卷是持久化存储的一种形式，可以在Pod重启时保留数据。持久卷控制器可以自动管理和扩展持久卷，以提高应用程序的可用性和可靠性。
2. 选择合适的存储策略
根据应用程序的需求，为Pod定义存储策略。例如，可以根据数据重要性和备份需求选择不同的存储策略。确保Kubernetes集群中的存储组件和Pod受到适当的安全性和访问控制措施的保护。可以使用身份验证、授权和访问控制列表来保护存储资源。并根据应用程序的需求，为Kubernetes集群配置自动扩展和缩减功能。这样可以提高资源利用率，并确保应用程序能够快速响应负载变化。
3. 做好备份与恢复
确保Kubernetes集群中的数据得到备份和恢复。可以使用第三方工具或Kubernetes原生功能来实现备份和恢复。
4. 监控
监控Kubernetes集群中的存储组件和Pod，以确保它们正常运行。可以使用Kubernetes监控工具和日志记录工具来实现这一点。
五、 最佳实践
1. 选择合适的存储策略
根据应用的需求选择合适的存储策略，如NFS适用于小规模的数据共享，S3适用于大规模的分布式存储，Redis适用于高速缓存和临时数据存储。同时，需要根据应用的特点进行存储的优化，如调整NFS的挂载选项、优化Redis的数据结构等。
2. 配置存储卷
在Kubernetes中，存储抽象是一种机制，用于将底层存储系统与应用程序解耦，使应用程序能够以一致的方式访问不同类型的存储资源。它提供了一种标准化的方法来管理和使用存储，并使开发人员能够在不了解底层存储实现细节的情况下进行操作。
Kubernetes中的存储抽象主要包括以下概念：
存储卷（Volume）：存储卷是一个抽象的概念，它表示可供Pod使用的持久化存储资源。存储卷可以映射到底层存储系统的各种类型，如本地磁盘、网络存储、分布式文件系统等。存储卷可以在Pod中被挂载为容器的一个目录，从而使容器能够读写数据。
存储类（StorageClass）：存储类是一种用于动态创建存储卷的抽象概念。它定义了存储卷的属性和行为，并将其与具体的存储后端绑定。存储类允许管理员为不同的存储需求定义不同的策略，并根据需要自动创建相应的存储卷。
持久卷声明（PersistentVolumeClaim）： 持久卷声明是用于请求存储资源的声明，它描述了应用程序对存储的需求。 持久卷声明提供了一种标准化的方式来定义存储需求，并使应用程序能够独立于底层存储实现进行操作。 管理员可以根据持久卷声明动态创建符合要求的存储卷。
持久卷（PersistentVolume）：持久卷是一个集群级别的存储资源，它与具体的存储后端绑定。持久卷由管理员手动创建或由存储类动态创建，并可以被多个Pod共享。持久卷提供了一种持久化存储的机制，使得数据在Pod重新调度、失败恢复或水平扩展时不会丢失。
在Kubernetes配置文件中，通过定义PersistentVolume（PV）和PersistentVolumeClaim（PVC），为容器配置存储卷。这使得容器可以持久化存储数据，并在容器重新调度或重启时保持数据的一致性。
在Kubernetes中，一般通过创建持久卷（表示底层的存储资源）、创建持久卷声明（用于请求存储资源，主要描述应用程序对存储的需求，包括访问模式、容量、存储类等）、挂载存储卷（提高数据存储和读取的效率）等步骤配置存储卷。
3. 使用容器原生存储解决方案
一些容器原生存储解决方案（如Portworx或Rook）可以与Kubernetes无缝集成，提供可靠的存储服务。这些解决方案可以自动管理存储卷、备份和恢复等任务，从而减轻运维人员的负担。
4. 存储插件的选择与配置
Kubernetes允许用户通过存储插件来扩展和定制存储功能选择合适的存储插件是云原生部署中非常重要的一步，它可以影响到应用程序的性能、可靠性和扩展性。以下是一些常见的存储插件以及它们的配置和使用方法：
1) NFS插件：
NFS（Network File System）是一种分布式文件系统，可以通过网络共享文件。NFS插件允许容器直接访问NFS服务器上的文件，并将其挂载为容器内的目录。
2) Ceph插件：
Ceph是一个开源的分布式存储系统，提供了对象存储、块设备和文件系统等多种接口。Ceph插件可以将Ceph集群中的存储资源与Kubernetes集群集成起来。
3) GlusterFS插件：
GlusterFS是一个开源的分布式文件系统，可以将多个存储节点组合成一个逻辑卷。GlusterFS插件允许容器直接访问GlusterFS卷，并将其挂载为容器内的目录。
4) CSI插件：
CSI（Container Storage Interface）是一种标准化的存储接口，可以与多种存储后端进行集成。CSI插件可以通过CSI接口与存储后端通信，并提供存储功能给Kubernetes集群使用。
5. 监控和调整
监控云原生存储的使用情况，确保存储资源的可用性和性能。根据需要，可以调整存储类、持久卷声明等配置参数，以满足应用程序的需求。
一般常见的有采用prometheus-operator来监控Kubernetes集群。
六、 价值和经验教训
信创云原生与存储结合，是容器化环境中的重要的角色，它提供了一种可靠、可扩展的持久化存储解决方案，具有很高的价值，具体体现在：
数据持久化存储，不会丢失：云原生存储可以将应用程序的数据持久保存在存储卷中，即使容器被重新调度或重新启动，数据也不会丢失。这为有状态应用程序（如数据库）提供了必要的持久化支持。我们经常用其使用存储卷来存储日志文件，以便进行故障排除和审计，并且不会因为容器的生命周期而丢失关键的日志信息。
方便的动态卷管理：可以通过声明式方式创建、删除和管理存储卷。它简化了存储资源的管理工作，减少了手动干预的需求。卷的动态可调整，便于根据应用程序的需要，动态调整存储卷的大小，以满足数据增长或缩减的要求，而无需停止或重新部署应用程序。极大的方便了忙闲时候的应用资源缩放，极大的提高了利用率。
多种存储后端支持：提供了对多种存储后端的支持，包括本地存储、网络存储和云存储等。这使得用户可以根据应用程序的需求选择最适合的存储解决方案。
数据共享和多点访问：支持多个Pod之间共享同一个存储卷，这对于需要多点访问数据的应用程序非常有用。我们可以很容易地扩展分布式应用程序或数据库集群。只需增加更多的Pod来处理更多的请求，并且它们都可以访问共享的存储卷，从而实现水平扩展和负载均衡。
但是在使用过程中，有一些注意点：
了解存储后端的性能和限制：不同的存储后端具有不同的性能和限制。在选择存储后端时，需要了解其性能特征以及与应用程序需求的匹配程度。例如：在选择网络存储后端时，了解其IOPS（每秒输入/输出操作数）和吞吐量等性能指标。如果应用程序需要高性能的存储，则可以选择支持更高IOPS的存储后端，如SSD存储。同时了解存储后端的容量限制，确保存储卷不会超出存储后端的可用空间。
注意数据持久化和备份：尽管原生存储提供了数据持久化的功能，但仍建议定期进行数据备份。这可以确保在发生故障或意外情况时能够恢复数据。例如：通过定期创建快照来备份存储卷中的数据，以便在发生数据丢失或损坏时进行恢复。这可以通过使用存储后端提供的快照功能或其他备份工具实现。我们有时也将存储卷的备份复制到不同的区域或存储区域，以防止单个区域的故障导致数据丢失。
考虑安全性：存储卷中的数据可能包含敏感信息，因此在使用原生存储时要注意确保数据的安全性。这包括对存储卷进行加密、访问控制和审计等。例如对存储卷进行加密以保护数据的机密性。可以使用云原生的透明加密功能或存储后端提供的加密选项。
在基础加密之上，做好权限访问控制，比如使用RBAC（基于角色的访问控制）或其他身份验证和授权机制，限制对存储卷的访问权限，并确保只有授权的实体可以读取和修改数据。
定期监控和调整存储资源：随着应用程序的变化，存储需求也可能会发生变化。定期监控存储资源的使用情况，并根据需要进行调整，以避免资源瓶颈或过度分配的问题。常使用Prometheus等监控工具监测存储资源的使用情况，包括存储容量、IOPS和吞吐量等指标。通过设置警报规则，及时发现并解决潜在的资源瓶颈问题。还根据应用程序的需求和存储资源的使用情况，定期调整存储卷的大小或类型，以满足应用程序的性能和容量要求。例如，根据数据增长情况，适时扩展存储卷的容量。
七、结语
信创云环境下，云原生技术的快速迭代为开发提供了快速部署、上线的能力。同时不能忽视持久化数据的安全、可靠、完整等企业级要求。云原生数据存储需要综合考虑分布式架构、高可用性和可靠性、弹性扩展、数据安全性以及性能优化等方面，以支持大规模数据的存储和处理，并确保数据的安全可靠和高效利用。
阅读更多《迈向YB数据时代》精彩内容，请识别以下二维码：
《迈向YB数据时代》
在信创云建设及应用浪潮中，以云平台为代表的基础资源底座成为各大企业的不二之选，传统业务如何迁移到信创云平台，信创云平台中的业务如何安全稳定运行，其中重要一环就是存储的规划与建设。如何建设信创云平台存储以实现业务稳定与创新并举，是金融企业数字化转型过程中要面临的重要挑战。
《迈向YB数据时代》 2023夏季刊 为此提供了深入的洞察和实践建议。本刊内容丰富，从业务需求、技术路线选择、产品选型、关键架构设计等多个角度进行深入探讨，旨在帮助金融企业理性决策，实现信创云趋势下的存储应用及建设的最优化。无论是正在考虑信创云下存储建设的企业，还是已经在信创云环境中运行的企业，都将从本刊中获得宝贵的启示和指导。
-
2023年夏季刊【最佳实践】议题一： 信创云环境下，一般类应用服务器（通用云主机）应用场景下，如何部署对象存储和 NAS 存储？
-
2023年夏季刊【最佳实践】议题二： 信创云环境下，企业级国产数据库的数据存储的应用场景下，如何部署集中式存储和分布式存储？
*本公众号所发布内容仅代表作者观点，不代表社区立场