如何在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上提供较好的服务质量。另外，运营人员需要考虑数据库支持的复制模式，异步复制可能产生数据遗失等问题，因为交易可能只提交到主数据库，而没有传送给辅助数据库，运营人员需要靠考虑数据遗失，以及可接受遗失的数据量。