关于云原生存储工具选用那些事儿和实际应用的一些想法分享

开始）

前段时间,我们团队正好在为一个新项目做技术选型，其中一块硬骨头就是云原生存储，说实话，这事儿折腾了我们不少时间，也走了些弯路，今天我就把这些零散的思考和实际碰到的情况，像聊天一样分享一下，不是什么权威指南，就是一些实战中的体会。

咱们得搞清楚为啥云原生存储这么“麻烦”。

以前用虚拟机的时候,存储这事儿相对简单，一块磁盘挂上去，格式化成ext4或者xfs，应用就往里读写数据，磁盘和虚拟机基本是“终身绑定”的，但到了云原生和Kubernetes（K8s）这个环境里，一切都变了，应用变成了一个个可以随时创建、销毁、迁移的 Pod（可以理解成一个包装应用的容器组），今天这个 Pod 可能运行在A服务器上，明天可能就因为调度策略跑到B服务器上去了，这时候，如果数据还死死地绑在A服务器的那块本地硬盘上，那不就麻烦了吗？Pod 一迁移，数据就丢了。

云原生存储要解决的核心问题就是：如何让数据能够“跟着应用跑”，或者至少能让应用无论在哪里跑，都能“找得到、用得上”这些数据。 这就引出了各种不同的存储方案。

面对五花八门的存储工具，我们是怎么想的？

当时我们面前主要摆着几条路,各有各的优缺点，选哪个真得看自家业务的“脾气”。

第一条路：直接用云厂商提供的“托管式”存储。 比如阿里云的云盘、文件存储NAS、对象存储OSS，或者AWS的EBS、S3这些，这是我们最先考虑的方向，因为它们最大的优点就是“省心”，云厂商帮你把底层的数据可靠性、扩容、备份这些脏活累活都干了，你直接用就行，而且它们通常和K8s服务集成得很好，通过一个叫StorageClass的东西就能动态创建存储卷。

• 实际应用想法： 我们当时评估，如果应用是那种无状态的，或者产生的数据可以很方便地扔到对象存储（比如图片、视频、日志文件），那肯定首选云厂商的服务，像OSS/S3，通过SDK访问，简直太方便了，根本不用操心容量问题，对于一些需要共享读写的场景，比如多个Pod要同时读同一个配置文件或者网站静态资源，文件存储NAS就是个不错的选择，对于像数据库这类对延迟和IOPS（可以理解为读写速度）要求很高的有状态应用，我们就得掂量一下了，云盘（块存储）的性能虽然不错，但成本相对高，而且跨可用区的数据同步又是另一个需要额外考虑的问题。

第二条路：拥抱“开源”的自建方案。 这类工具的代表是Ceph、Longhorn、Rook之类的，它们的特点是你可以在自己的服务器集群上，或者在任何云上，自己搭建一套分布式的存储系统。

• 实际应用想法： 选择自建方案，通常有几个原因，一是为了避免被某一家云厂商“绑定”，追求更高的灵活性，将来想换云环境会比较容易，二是对数据有极强的控制欲，觉得数据放在自己搭建的系统里更安心（虽然运维复杂度也上去了），三是可能云厂商提供的存储服务成本超出了预算，自己搭建长期来看更划算。
  • 我们当时重点研究了Longhorn，它给我的感觉特别“云原生”，设计理念就是为K8s而生的，它通过在每个节点上装一个轻量级的组件，把各个节点的本地硬盘空间聚合起来，变成一个统一的、可备份、可复制的块存储池，它的管理界面非常直观，能清晰地看到每个数据卷的状态和副本分布，故障恢复也比较简单，对于中小规模的集群，或者刚开始接触云原生存储的团队，Longhorn的入门门槛相对较低。
  • 而像Ceph这样的“老牌劲旅”，功能无比强大，规模可以做到非常大，可靠性经过无数生产环境验证，但它的复杂度也高得多，需要专门的存储运维知识，对我们这种应用开发为主的团队来说，学习和运维成本有点高，如果用Rook这个Operator（可以理解为K8s上的自动化运维管家）来部署和管理Ceph，能省不少事，让Ceph在K8s上的体验更顺滑。

第三条路：本地存储的“倔强”。 一些应用对性能的要求达到了极致，比如AI训练、大数据分析，需要极低的延迟和超高的吞吐量，这时候，网络存储带来的那一点点延迟都可能成为瓶颈，那怎么办？只能“委屈”一下，让Pod固定在某些具有高性能本地SSD硬盘的节点上运行，数据就存在本地。

• 实际应用想法： 这种做法牺牲了Pod调度的灵活性，变成了“应用找数据”，而不是“数据跟应用跑”，我们在做高性能计算类项目的技术支持时，就用了这种方式，我们需要用K8s的节点选择器（nodeSelector）或者节点亲和性（nodeAffinity）把Pod牢牢地“钉”在特定的机器上，必须做好数据的本地备份和容灾方案，因为一旦这台机器宕机，虽然数据还在盘上，但应用会中断，需要手动干预恢复，这算是一种为了性能而做的妥协。

我们的一些核心体会：

1. 没有银弹，只有权衡。 不存在一个能解决所有问题的存储方案，选型的核心是搞清楚你的应用场景：数据需要被多个Pod共享吗？对性能的要求有多高？能接受多高的延迟？数据的持久性级别要求是多少？预算有多少？
2. 从“省心”开始，逐步深入。 对于大多数团队，我建议优先考虑云厂商的托管服务，尤其是对象存储和文件存储，先把业务跑起来，把精力集中在核心业务逻辑上，当业务发展到一定规模，对性能、成本、多云策略有了更明确的需求时，再考虑像Longhorn这样的自建方案。
3. 备份和容灾永远是重中之重。 无论选用哪种存储工具，一定要设计好数据的备份、恢复和容灾策略，比如Longhorn自带的快照和备份到S3的功能就很好用，云厂商的存储服务也通常有跨可用区复制的选项，千万别等到数据丢了再后悔。
4. 测试，测试，再测试。 在决定采用某个方案前，一定要在测试环境进行充分的压力测试和故障演练，模拟节点宕机、网络分区、磁盘损坏等场景，看看你的存储系统和应用的恢复能力到底如何。

云原生存储的选用是一个结合了技术、成本和团队能力的综合决策过程，它不像选编程语言那样有明确的优劣，更多的是场景的匹配，希望我们这些摸着石头过河的经验，能给你带来一些启发。 结束）