k8s容器内的东西复制出来_数据库适合迁移到K8S上吗？

经常有朋友和老白探讨，在容器云发展到现在的时候，是不是已经到了可以把数据库也迁移到K8S上的时候了。实际上这个问题还真的不好回答，很多IT界的问题不好回答的原因是，任何一个问题都只有一个事实，而回答这个问题的所有人讲的都只是观点，而不是在陈述这个事实。既是观点，那么就无所谓对错。老白不是个喜欢争论的人，十多年前在Oracle.com.cn或者itpub上，也只是谈一下自己的观点，而不喜欢争论。因为无论怎么争论，都只是在兜售自己的观点而已，并不一定是在普及事实。要回答这个问题实际上是十分复杂的，每个使用数据库的人都有自己的特殊需求和特殊的环境背景。要想回答好这个问题，我想先考虑清楚几个问题就可以了，首先K8S是个什么东西，它能支持什么样的业务？其次，你使用K8S跑数据库的目的是什么？你的数据库跑到K8S上的好处是什么，坏处是什么？第一个问题是要解决k8s能不能跑你所需要的数据库的问题，实际上k8s最初的设计是运行一些无状态的微服务的，而不是为有状态的数据库设计的，随着K8S的演进，对有状态负载的支持也越来越好了，特别是StatefulSets技术就是为了支持各种有状态负载的。因此并不是所有的数据库都是k8s friendly的。谷歌云解决方案架构师本杰明.古德画过一张你的数据库应该跑在什么样的环境中的导图，我觉得是十分具有参考意义的。 第一个选项要回答你的数据库是不是k8s友好的。由于容器较物理机、虚拟机等环境是更容易出现故障的基础设施， 因此故障自动转移事件的发生可能性比传统托管或完全托管的数据库高。 数据库中包含分片、故障转移选择、自动副本复制功能的数据库都是属于k8s友好的数据库，比如 ElasticSearch，Cassandra或MongoDB等。而Mysql、Pg、Oracle等数据库则是非k8s友好的数据库。 对于非 k8s 友好的数据库，如果 具有 较好的 k8s上的运行支撑，比如借助于一 些Operator 来实现 数据自动复制/备份， 故障自 动转移等特性 ，并且组织能够 提供足够的 运维 支撑， 那么 也是可以 转回使用k8s这条 线的。然后我们要回答下面的一个选项，就是数据库的工作负载是不是适合k8s，如果这个数据库是一个负载不高，并且随着应用上线后，负载增加不是很大(如果有较大的负载，可以通过横向扩展，而不是增加在一个独立的数据库上)，那么这个工作负载就是k8s友好的，可以使用k8s。反之，如果这个数据库工作负载很大，或者存在十分高的高峰，或者随着上线时间推移，数据量增长很快，负载会越来越大，而且无法很好的横向扩展，那么这个工作负载是非K8S友好的。然后进入第三个选项环节，你的工作负载能支撑多大的并发量，如果你可以完全控制并发量，让k8s能够承受合理的工作负载，那么你就放心的在k8s上跑你的数据库吧，否则还是让数据库跑在一个完全受控的环境下。这里古德把数据库的运行环境分为云服务、完全受控环境(云主机或者物理机)和k8s三种。关于其他的选择大家可以自己看这张导图，因为时间关系我们就不再展开。已经完成了第一个问题选择的朋友，我们可以继续看第二个问题。你为什么要让你的数据库跑在K8S上。为了快速部署、随意迁移还是便于管理？如果为了快速部署，你的快速部署要求是什么？有多快，是按天、按小时还是按分钟，秒钟？如果你需要以分钟级或者秒钟级部署，那么K8S可能是最好的选项之一，否则，虚拟机或者云服务可能是更好的选择。其次 你的数据库有 很 明确的随意迁移需求吗？ 可能绝大多数准备把数据库上k8s的用户都没有这个需求。如果你把k8s看作是解决数据库负载过大或者数据库不宜管理的良方，那你可能真的抓错药了。k8s并不能解决你你以往的数据库问题，k8s是为微服务而生的，不是解决传统问题的灵丹妙药。回答第二个问题很简单，就是考虑清楚，你的数据库上k8s的利弊是什么，最终根据利大于弊的原则去做选择就可以了。这个问题没有标准答案。