昨天冯老板发了一篇文章讨论为什么把数据库放到K8S不是一个明智的选择：
如果四年前有人质疑容器化数据库，我认为战斗是可以的。 已经2023年了，仍然有人无法认识到这一趋势。 我有必要谈谈我的看法。
我从 K8s 0.9 版本开始就一直这样做。 那个时候确实有点早，CSI还没有成熟。 它在 1.0 中只是稍微稳定一些。 当时我在科大讯飞工作，负责的项目是搭建和维护一个完整的系统。 该系统最终支撑公司内部的PaaS服务。
我们构建了一个由 30 台物理机组成的集群。 这个集群虽然小，但是技术含量很高。 它运行近3000个各种类型的应用程序，包括但不限于微服务、数据库和消息队列。 、缓存等。这个集群是公司内部几百个开发者同时使用的，但是整个集群的运维只需要不到一半的人力就可以完成。 如果没有 K8s，这将永远不可能。
我们也在不知不觉中升级了Linux内核，且不影响上层应用。 这种潜移默化的升级如果没有K8s的支持是难以想象的。 仅仅与各个业务线的沟通可能就需要半年的时间。
我见过另一个集群只跑了400个数据库、400台服务器、40人的运维团队。 集群整体利用率不足10%。 整个集群没有人敢动，所以只能装满人，由人类来操作和维护。 虽然这种情况可以归因于组织方面的不专业，但实际上许多团队面临着类似的挑战，无法有效管理和优化其基础设施。
后来去了阿里巴巴，所有配送场景数据库都跑在K8上。 到目前为止，我们在容器中运行数据库已经五年多了，零故障。
k8s上的数据库：专业能力普及
大多数做业务的公司在数据库处理方面通常存在两个问题：要么数据库管理水平一般软件 鲁棒性，不能充分发挥数据库的潜力；要么数据库管理水平一般，不能充分发挥数据库的潜力； 或者他们每年需要在数据库管理上花费大量资金。 K8s 上的数据库可以标准化这一切。 有了标准，人们就可以协作，生产力改变了生产关系，从而大大提高了效率，让绝大多数没有专业能力的团队也能享受到专业能力，从本质上分工。 更清晰，就像农业和畜牧业分开一样，各自专注于自己的领域，从而提高整体效率和产量。
以KubeBlocks团队为例，我相信大多数公司在数据库层面没有他们那么多的积累和专业能力。 并且他们将这些实践经验转化为代码，编写控制器，以极其简单的方式为其他公司赋能。 K8s 使这成为可能。
你可能会问：为什么不使用 Ansible？ 运维人员可能会欣赏Ansible，因为它与他们手头的工具相匹配并且易于使用。 Ansible的核心思想是帮助用户部署和执行运维操作，而K8s控制器则基于另一个思想：机器能做的事情不应该由人类来做。 通过Operator，可以实现期望状态与实际状态24小时不间断同步，这是Ansible很难实现的。 使用Ansible时想写一个计划任务吗？
就像操作系统出现之前，程序员必须手动在纸带上打孔才能运行程序。 有人可能会说，如果可以在纸带上运行程序，甚至可以将程序刻录到光盘上运行，那为什么还需要操作系统呢？
道理是一样的：Ansible 对于运维人员来说是一个很棒的工具，但 K8s 的目标是消除低端运维工作（即编写和执行 Ansible 脚本的工作）。 通过K8s，我们可以实现更加高效、自动化的数据库管理，让不具备专业数据库管理能力的团队也能享受到专业级的服务。
K8s上数据库的优势
大多数人对在 K8 上运行数据库的担忧集中在以下问题：
不确定稳定性？
有一个问题我无法解决？
是不是性能不够好？
复杂性
在K8s上运行数据库时，复杂度主要分为两个方面：
构建这个系统的复杂性
使用的复杂性
第一：构建这个系统的复杂性
如果直接基于原生K8s（裸K8s）搭建数据库系统，成本会比较高，而且对于新手来说，这样的操作并不友好。 您需要自行构建K8s存储驱动、数据库控制器等多个组件。 没有深厚的专业知识和实践经验是不可能做到的。
这时候分布的优势就体现出来了。 与Linux系统类似，大多数人更喜欢使用CentOS和Ubuntu等发行版，而不是直接操作内核。 我们也可以将K8s视为“云内核”。 如果你直接使用内核而没有进行适当的定制和优化，你可能会觉得它不够有用。 由于内核本身只提供了一个框架，很多功能和优化都需要用户自己实现。 K8s发行版帮助用户解决了这个问题。 例如，Sealos可以帮助您一键构建包括高可用集群、存储插件和数据库的完整系统。 这一切只需要两个简单的命令：
$ sealos run labring/kubernetes:v1.27.7 labring/helm:v3.9.4 labring/cilium:v1.13.4 \
--masters 192.168.64.2,192.168.64.22,192.168.64.20 \
--nodes 192.168.64.21,192.168.64.19 -p [your-ssh-passwd]
$ sealos run labring/openebs:v3.9.0 labring/mysql:8.0
如此一来，一个包含高可用集群、存储插件和数据库的系统就诞生了。 虽然 Ansible 可以帮助你解决安装问题，但它无法处理运行时自愈、多租户等问题，而在 K8s 上可以将数据库做成 Service。
第二：使用的复杂性
通过云操作系统分发和控制器，用户可以实现产品化的数据库服务，而不是依赖脚本来解决问题。
我相信没有人会使用这个页面吧？ 即使像我这样的新手也有能力搭建一个3副本的PostgreSQL集群，包括备份、恢复和监控功能。 这种能力不仅可以赋予企业内所有开发人员，还体现了“云计算思维”与“脚本思维”的根本区别。 云计算让每个人都可以提供服务（as a Service），而传统的脚本方式只是运维人员的一个便捷工具。
稳定
我们的团队在数据库领域甚至不是专业的，但我们已经能够建立一个相当稳定的数据库系统，更不用说专门从事这个领域的顶尖专家了。 用户无需担心这个问题，交给专业人士即可。
例如，Sealos 公有云目前运行着数千个应用程序，这些应用程序的数据库已完全容器化并由 KubeBlocks 团队提供支持。 一旦数据库出现问题，我们就把问题扔给他们。 从成本角度来看，招聘DBA的成本远高于我们为KubeBlocks商业版本支付的费用，而且Sealos也是平台的建设者，更不用说使用数据库的最终用户了。 从目前的运行情况来看，我们的稳定性已经远远超过了很多非专业团队的运维水平。
而数据库生命周期管理基本上就这么多了。 随着时间的推移，稳定性问题将会得到解决。 这些问题在代码层面不断得到解决，最终用户会越来越不关心。 这与Linux系统的稳定性类似。 随着技术的不断成熟和优化，其稳定性已经达到了很高的水平。 一个好的软件架构会不断提升和收敛其健壮性，并逐渐减少对人的依赖。 比如，使用Oracle的人一定比使用开源MySQL的人有更多的下午茶时间。
因此，无论实际情况还是理论分析，稳定性都不应该成为用户在K8s上运行数据库的障碍。 在k8s上运行数据库实际上是利用了数十位顶级数据库专家的经验。 他们将自己的知识和技能融入到代码中，以标准化的方式为用户服务。 单独使用脚本很难如此彻底、有效地传达这些体验。 。 单独使用脚本很难如此彻底、有效地传达这些体验。
表现
据说很大概率是数据库运行容器的性能不好，KubeBlocks团队做了深入的测试和调优，并写了一篇非常详细的分析文章。 很多人认为这确实很复杂，但实际上这种复杂的事情并不是用户不需要做的。 这些复杂性内置于控制器的代码中，使最终用户的过程变得简单。 而且，容器对数据库性能的影响几乎可以忽略不计。 真正重要的是磁盘 IO 和网络带宽延迟等因素。
OpenEBS裸盘+数据库控制器的方案可以有效解决性能问题。 有了数据库控制器，就不需要依赖分布式存储了。 控制器可以保证数据库多副本的高性能和高可用性。 无论是有状态服务还是无状态服务，用户都不会感觉到差异。 如果实例出现故障，控制器会自动调整。 这就是极致的数据库使用体验。
Sealos 目前采用了该解决方案，以在不牺牲性能的情况下确保高可用性。 可直接连接裸盘进行自动扩容、备份和恢复。 如果某个节点出现故障，控制器会自动启动一个新节点，同步数据并将其加入集群。 这些高级功能只有在云操作系统中才能实现，传统的脚本方式只能望尘莫及，而且后者通常需要人工干预。 比如半夜挂了，就只能打电话了。
因此，在K8s上运行数据库不仅没有性能问题，其稳定性甚至超过了大多数运维人员的能力。 而且，这种方法易于使用并且是自助服务。 你想使用它吗？
不要脱离实际场景去否定和肯定
在讨论数据库是否应该容器化时，我们必须考虑不同的实际用例。
有些公司的数据库已经以非容器化的方式运行得非常稳定，他们没有足够的资金来维护一批数据库专家。 在这种情况下，当然没有动力将数据库迁移到 K8s。 如果出现问题谁来承担责任？ 例如，银行通常使用专用的Oracle设备，只需支付订阅费。 很难有动力去迁移这样的系统。
然而软件 鲁棒性，对于很多业务开发团队和组织来说，现在面临着新的选择：以极低的成本获得高度专业化的数据库能力，从而让核心团队完全专注于业务开发。
为了达到这种效果，他们可以选择直接使用RDS（关系数据库服务）等数据库云服务，或者采用基于K8s的数据库解决方案。 这种方法需要一个长期运行的管理流程来取代人类角色，从而为不懂数据库的团队提供支持。 这是一个大趋势。 固定成本（例如开发控制器的成本）增加了，但边际成本（每个团队使用数据库的成本）将显着降低。
目前有很多解决方案可以做到这一点，比如基于虚拟机或基于Ansible，但毫无疑问基于K8s的控制器是目前最优的解决方案。 即使提供类似RDS能力的服务，底层使用k8s技术栈也是最优方案。 相比之下，虚拟机的功能并不是很强大，而且笨重，成本自然就高，而且消耗的性能也更多。 在实现自助服务和多租户支持方面，像 Ansible 这样的工具甚至更加异想天开。
总结K8s的重要性
K8s 是一个强大的武器。 比如你可以发挥无崖子16%技能的10%。 如果K8s不运行数据库，你可能只能发挥1%的威力。 用好K8s可以大大提升数据库运维的效率。
技术进步带来的分工变化
随着技术的不断进步，数据库管理者和用户将逐渐分离，传统的手工操作逐渐被自动化程序所取代。 在此过程中，标准化成为有效协作的基石。 目前还没有比容器技术和K8s更强的事实上的标准。 因此，数据库运行在K8s上是大势所趋。
实际案例及效益
目前，很多团队已经在成本、易用性、稳定性、性能等多个维度成功实施了K8，取得了显着的效果，并尝到了这样做的好处。 从奢侈到节俭是很难的。 企业一旦体验到K8s带来的好处，就很难再回到传统的运维方式了。 以西洛斯为例。 从v2使用ansible，v3完全切换到golang，现在已经发展到v4、v5。 这项技术的演进是基于“云计算”和“云操作系统”的思维，而不是传统的“运维脚本”思维。脚本甚至无法实现你我谈论的先进生产力API？设计一个系统的优先级不一定是让人用，而是能被其他系统调用，这样整个自动化才能起飞，这就是为什么API>CLI>GUI。
运营和维护角色的变化
目前现有市场上仍有不少DBA运维人员想保住饭碗，对这个方向持悲观态度。 然而，明智的决策者迟早会发现，采用K8可以显着降低人力成本，提高效率和系统稳定性。 好鸟会选择合适的树来栖息。 希望很多运维同学认识到，你正在逐渐被取代是一个事实。 我们做科大讯飞的时候，我们有一个近40人的运维团队。 之后我们连运维组都没有了。 。 我们在阿里云的时候，我们团队也是零运维人员。
K8s的快速成熟和生态发展
K8s正在以极快的速度变得更加成熟，生态系统蓬勃发展，造成短期混乱，实施混乱。 不过不用担心，优秀的发行版肯定会出现。 发行版都在做“熵减”来简化用户体验，就像从Linux内核到Linux发行版的演变一样。 Sealos 是基于 K8s 的其中之一。 云操作系统分发。 我最近走访了近200个Sealos的付费用户，没有一个人反映上述数据库无法使用，有的人反映由于磁盘已满、升级导致的问题等多种原因导致数据库不稳定。问题都收敛了，最后逼近了0，至少可以说比用户自己建的稳定了几个9。
商业选择
企业是否选择这样的解决方案取决于企业的实际情况，但聪明的企业在尝试使用K8s上的数据库后将带来巨大的好处。 例如，选择 Sealos + KubeBlocks 的组合相当于拥有：
拥有8年以上经验的专业K8s团队。
一个P10领导着一个P8-9的顶级专业数据库团队。
极其人性化的产品体验、极其健壮、极其高性能的数据库系统。
它甚至不比聘请专家的成本低。 当然，这种选择必定会遇到阻力。 大多数阻力来自公司内部的人，如果他们想保住工作，他们并不真正需要它。
我本可以一一反驳冯老板的论点，但我还是太累了，无法同时读书和写作。 我正在分段阅读这些，希望看到有多少人能够有更深入的理解，也希望听到更多的支持。 或者反对我们的声音，一起探索真相~
加入 Sealos 开源社区
体验像PC一样简单的云操作系统
官网链接
GitHub地址
访问 Sealos 文档
️访问论坛
过去推荐的
关于西洛斯
Sealos是一个以Kubernetes为核心的云操作系统发行版。 以云原生的方式，放弃传统的云计算架构，转向以Kubernetes为云核心的新架构，让企业像使用个人电脑一样简单地使用云。
关注Sealos公众号，与我们一起成长
