认识达内从这里开始

随着互联网的不断发展，越来越多的企业都实现了云技术的转型应用发展，而今天我们就通过案例分析来了解一下，在Kubernetes上运行的数据库的方法都有哪些。

1、在Kubernetes上运行的数据库的方法

尽管在应用层(applicationlayer)的容器化有了大量增长，但数据层(datalayer)在容器化方面得到的关注并不多。这很正常，因为容器化工作流本来就需要足够的弹性，才能应对重启、扩展、虚拟化和其他限制。所以处理数据库的可持久化、对应用程序其他层的高可用性和数据库的冗余等方面，有非常具体的要求。这就使得数据库在分布式环境中运行起来很有挑战性。

然而，数据层得到更多关注，是因为很多开发者想要像处理应用层技术栈一样，处理数据层基础架构。运维人员希望使用的同样的工具来运维数据库和应用程序，而且数据层和应用层能达到相同的收益：跨不同环境的快速启动和可重复自动完成。在这篇文章中，我们将探讨什么时候，以及哪些类型的数据库可以在Kubernetes上有效运行。

在深入探讨Kubernetes上运行数据库的注意事项之前，我们先简单回顾一下GoogleCloud平台(GCP)上运行数据库都有哪些选项，以及这些数据库的用法。

完全托管的数据库。包括CloudSpanner、CloudBigtable和CloudSQL等。这些都是低运维成本的选则，因为GoogleCloud会承担很多日常维护的工作，如备份、补丁和扩展等。开发者或运维人员无需人为干预，只要创建一个数据库，构建自己的APP，然后交给GoogleCloud进行扩展。这也意味着你可能无法使用到自己想要的数据库版本、扩展或某种类型的数据库。

在虚拟机上自行操作的数据库。也可称为「全运维选项」，构建数据库、扩展数据库、管理可靠性、配置备份等通通需要自行设定。这虽然工程量巨大，但所有的功能和数据库类型的选择都在自己的掌握之中。

在Kubernetes上运行的数据库。在Kubernetes上运行数据库更接近于全运维选项，但是可以从Kubernetes提供的自动化功能中，享受一些好处，以支持数据库应用程序的运行。话虽如此，但需要记住的是，Pods(数据库应用容器)是瞬时性的，所以数据库应用重启或故障切换的可能性较大。此外，由于容器化后增加了抽象功能，一些数据库管理任务，如备份、缩放、调优等，都是不一样的。

2、在Kubernetes上运行数据库的技巧

如果选择走Kubernetes路线，你需要思考运行哪些数据库，以及当通盘考虑前文讲到权衡时数据库运行状况。由于Pods至关重要，因此发生故障转移事件的可能性，比传统部署或完全托管的数据库要高。如果这个数据库内置支持分片(sharding)、故障选举(failoverelection)和复制等设计(例如ElasticSearch、Cassandra或MongoDB)，那么在Kubernetes上运行会更简单。一些开源项目提供自定义资源和控制器，来帮助管理容器化的数据库。

考虑数据库在应用和业务的上下游中起到的作用。存储更多临时的和缓存层的数据库更适合Kubernetes。这种类型的数据层通常在应用中更有弹性，整体体验更好。

确保你了解数据库中可用的复制模式。异步传输模式可能会出现数据丢失，因为数据库事务(transaction)可能会被提交到主要数据库，而不会提交到次要数据库。因此，一定要明确是否会产生数据丢失，以及在自己的应用程序中，有多少数据丢失是可以接受的。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。