哪个医院治白癜风最好 http://m.39.net/pf/a_4618897.html昨天老白讨论的话题是关于是否可以把数据库迁移到K8S上，实际上老白对部分数据库负载运行于K8S是持肯定态度的，目前D-SMART也正准备在下一个小版本中提供对运行于容器中的数据库的全面支持（目前的D-SMART虽然能够监控K8S里的数据库实例，但是其监控指标体系与健康模型并不完善）。因为篇幅关系，昨天我们并未就很多问题进行展开，特别是如何根据工作负载来判断是否要使用容器。作为开发环境或者测试环境的数据库在K8S里跑大家都没有太大的异议，这里也就不多谈了。重点谈生产环境下什么样的负载适合使用K8S。大家都认为K8S下部署数据库的成本是比较低的，实际上这是有一定的前提条件的。如果我们需要部署几十个、数百个甚至数千个工作负载类似的数据库，那么使用K8S部署这些数据库可以使用统一的模板，这种部署成本是最低的。如果每个数据库实例都需要特定的定制，那么这种模式下，K8S部署和VM部署或者使用RDS云服务的差异就不大了。从应用的角度上看，如果我们的微服务中需要使用内部数据库，这些数据库中存储的数据只是与微服务相关，并不和外界有过多的数据交换，那么这些与微服务紧密集成的数据库通过K8S来部署与管理，是十分适合的。我们可以称这种数据库为微服务数据集。如果你的环境中大多数数据库都是较为固定的负载与配置，很容易模板化，那你的大多数数据库是可以在K8S上跑的。对于特定负载或者配置的数据库，比如需要较大的IO吞吐能力，较小并且极为稳定的IO延时，更多的CPU资源，那么这些特殊需求的数据库还是使用虚拟机比较好。工作负载高低差异较大的数据库系统，虽然也可以使用特殊的K8S节点池的方式来提供支持，但是如果最高负载比较高，单实例内存需求较大、IO吞吐量要求较大的数据库，选择使用虚拟机肯定比强挺着使用K8S要好得多。对于经常需要针对性调优的数据库系统，也不适合使用K8S，因为调整后，有可能该数据库运行的K8S节点池就不太适合部署这个数据库了，经常出现这样的切换，对于K8S的维护来说，也是一种灾难。K8S比较适合那些负载较为稳定，只需要通过K8S集群来自动管理的数据库实例，这些数据库最好都是不需要DBA给与