本文是2018年《Kubernetes上的PostgreSQL日历活动》的第二天。
昨天，我们整理了Kubernetes的现状和数据库的兼容情况，今天我们将讨论具体的PostgreSQL on Kubernetes构建和目标。

太长不看

• PostgreSQL on Kubernetesって複雑すぎない？

• データの冗長化はストレージレイヤで。

PostgreSQL on Rookの紹介。

当前在Kubernetes上的PostgreSQL存在的问题点。

我昨天介绍了Stolon作为一个案例。
同样，我们还有一个类似的案例，就是Crunchy Data的PostgreSQL on Kubernetes。

这些都是通过使用PostgreSQL的复制功能，在Kubernetes上部署一个主服务器和两个或多个备用服务器。
以下是这种配置的优点：

• 複数DBインスタンスによる耐障害性の確保

standbyのスケールアウトによる読み取り性能の向上

然而，我认为复杂的结构（即增加障碍点）和由此导致的可操作性下降是问题的一方面。

尽管我举了Vitess的例子，但大多数系统并不需要像YouTube这样大规模扩展，而且很多系统甚至不需要读取副本。

PGEcons提供的PostgreSQL的典型配置

虽然资料有点旧，但有一个名为PGEcons的组织正在整理「PostgreSQL的常见配置」。

这些信息可以大致归纳为以下5种模式。

1. 单服务器配置

1. 高可用性集群配置（共享存储方式）

1. 高可用性集群配置（共享无状态方式）

1. 流复制

使用pgpool或Slony-I进行软件复制

Stolon可以说是将Kubernetes和上面的第4点结合起来的构建。它在PostgreSQL层面上保证了数据的冗余性。

然而，我们不能在更低的层面上保证冗余性并采用更简单的结构吗？
换句话说，我们不能将上述的2或3与Kubernetes结合起来吗？

PostgreSQL在Rook上的实现

本次我们考虑在Kubernetes上运行Rook，一种共享式分布式存储，然后将其作为PostgreSQL的存储方式。

如上图所示，PostgreSQL本身被调度为一个简单的StatefulSet，无需额外的operator等。具体细节将在以后解释，但通过将由Rook部署的Ceph RBD卷作为PV挂载，可以确保数据的冗余性。

我认为肯定会有人质疑包含Rook和Ceph是否本身就很简单，但我认为它具有很多优点，比如不需要在多个数据库实例之间进行升级时的调解。

当然，在现阶段要对实际运作的想法有一个明确的概念，验证是必不可少的，但我希望能够在这次的Advent Calendar中逐步介绍它。

总结

为了延续昨天的话题，今次也讲了很多概念性的内容。
从明天开始，我们将准备启动Rook，这是本次讲话所必需的。

请多关照。