如何在Kubernetes构建数据库服务?

用户使用云数据库,现在有几种方法,包括在虚拟机或是Kubernetes上执行,或是直接采用完全托管的服务,Google对此提供了一些建议,供用户在选择数据库之前做参考。

Kubernetes的应用越来越热门,许多应用被容器化,甚至专门将软件容器化的服务也热门起来,但这个热潮并没有发生在数据库上,Google提到,可以容器化的工作负载,通常具有能适应频繁地重新启动、横向扩展、虚拟化等其他限制,因此数据库在服务的可用性等要求,限制了数据在分布式环境中执行的发展。

Google提到,但是仍有不少开发团队,希望数据库可以使用与应用相同的堆栈,而运营人员也能使用相同的工具管理。比起完全托管的数据库服务Cloud Spanner、Cloud Bigtable和Cloud SQL等,和在虚拟机上全自运营的选项,在Kubernetes上执行数据库虽然偏向全自运营,但是Kubernetes提供的自动化功能,是能为运营人员省掉一些麻烦,但Google提醒,运营人员要有心理准备,因为Pod状态仅为暂时性的,而且数据库应用重新启动与故障转移机率比较高,且数据库管理员的工作像是备份、扩展和调整等工作,会因为容器化新增的抽象层而不同。

由于Kubernetes的Pod是会消失的,因此故障转移事件性的可能性,会高于传统托管或是完全托管的数据库,而好处是,当要执行的数据库,需要包含分片、故障转移选择或是内建的复制等功能,那在Kubernetes上运营将会更容易,部分开源项目还提供自定义义资源以及运营工具,以帮助用户管理数据库。

Google制作了一个判定树图,供用户评估并选择适合的云数据库的方案,要在Kubernetes上构建数据库,最先需要了解的是,数据库的功能以及生态系统的项目是否对Kubernetes友善,再来还需要评估组织运营工作负载的能力,有充足的运营能力再选择在Kubernetes上自建数据库。

在数据库的选择上,Google表示,开发人员需要考虑数据库在应用和业务环境中执行的功能,存储较多暂时状态以及快取层的数据库,更适合在Kubernetes上运行,因为该类型的数据库通常拥有较高的弹性,因此也能够在Kubernetes上提供较好的服务质量。另外,运营人员需要考虑数据库支持的复制模式,异步复制可能产生数据遗失等问题,因为交易可能只提交到主数据库,而没有传送给辅助数据库,运营人员需要靠考虑数据遗失,以及可接受遗失的数据量。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190708A0BU4D00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券