Kubernetes和云数据库

时间:2018-09-09 09:02:39

标签: database kubernetes

有人可以通过持久卷声明结合存储卷而不是使用实际的云数据库资源来解释在Kubernetes中托管数据库的好处/问题?

2 个答案:

答案 0 :(得分:3)

从本质上来说,这是一个权衡:方便与控制。举一个具体的例子:假设您向Amazon支付钱来使用Athena,这实际上只是Facebook Presto的一个很好打包的版本,AWS会为您操作以交换$$$。您可以自己在EKS上运行Presto,但为什么要这样做。

现在,假设您要使用Apache Drill或Apache Impala。亚马逊不提供。据我所知,在撰写本文时,其他大型公共云提供商也没有。

另一个想法:如果要从AWS迁移怎么办?您的数据也具有引力。

答案 1 :(得分:2)

  

有人可以通过使用实际的云数据库资源来解释在Kubernetes中托管数据库的好处/问题吗?

如先前的出色回答所述:

  

这本质上是一个权衡:方便与控制

除了前面的示例(雅典娜)之外,还请看一下RDS,并了解您需要如何处理自己(如前所述,为什么要这么做):

  • 自动备份
  • 多区域部署
  • 快照
  • 引擎升级
  • 读取副本

以及托管服务随附的其他功能,与自托管/托管服务相反。

但是,我试图向这篇文章阐明的内容不只是方便/控制:

Kubernetes在此处添加了另一层抽象(pod,服务...),并且根据处理存储方式(持久卷)的不同,您可能还需要考虑两个方面:

  • 访问速度(根据您的使用情况而定,可能是疏忽大意或显示塞子)。
  • 手头的存储可能未针对I / O的关系数据库类型进行优化(或限制了您有效地调度Pod)。例如,不建议您在NFS上运行db的原因也是如此。

最近有很多关于kubernetes的会议演讲,指出数据库对于kubernetes来说是一个大的禁忌(尽管这是很自以为是的,我们确实在k8s中运行平均负载mysql和postgresql数据库),以及大负载/快速I / O相对于已经在托管云解决方案中为您进行了微调的人来说,正确使用k8有点困难。

结论:

这一切都与便利性,控件和功能有关。