在第二部分中，我们开始设计PostgreSQL控制器。 今天，我们从上次停下来的地方开始，然后开始详细介绍控制层(包括控制器和附带工具)如何跟踪PostgreSQL应用程序的状态。

PostgreSQL应用程序的真实状态包含许多组件：

· 每个PostgreSQL实例的当前状态(状态)：健康吗？ 是主服务器(主服务器)还是备用服务器(从服务器)？ 还在配置吗？

· 每个PostgreSQL实例的期望状态(规范)：应该是主要状态吗？ 它应该从哪里流式传输WAL(预写日志)？

· 整个应用程序的当前状态：哪些实例属于该PostgreSQL应用程序？ 备份写在哪里？

· 整个应用程序的期望状态：应该有多少个实例？ 备份到哪里去？

该真实状态在中央存储区中编码，控制层使用该状态来决定其需要做什么。 控制层的每个元素都负责维护部分编码状态：

· 无论是个人还是其他应用程序，应用程序管理员都负责设置应用程序整体的所需状态。

· 控制器维护整个应用程序的当前状态以及各个PostgreSQL实例的期望状态。

· 每个PostgreSQL实例均由Sidecar控制，该Sidecar负责维护实例的当前状态。

PostgreSQL实例状态

在第一部分中，我们介绍了PostgreSQL实例必须实现的一些行为。 例如，当主数据库启动时，它将执行以下操作：

· 初始化数据库，可能是从预先存在的备份中初始化。

· 配置连续备份。

· 配置流复制，包括身份验证机制。

我们如何编码实例的当前状态取决于我们是否将上述三个动作捆绑为一个步骤。 如果仅一步，状态转换可能看起来像这样：

· 未设定

· 完成设置

使用这种编码，控制器无法确定实例所处的设置步骤。根据整体设计，这可能很好。 如果控制器需要更多有关实例设置过程的可见性，则状态转换可能看起来像这样：

· 未设定

· 数据库已初始化

· 备份配置

· 完成设置

在这两种设计中，控制器设置的期望状态为：

· 完成设置

实例Sidecar尽其所能将其当前状态移至所需状态。

实例故障

到目前为止，我声称PostgreSQL实例sidecar负责维护中央存储区中编码的当前状态。 这并非完全正确。

当PostgreSQL实例Pod发生故障(由于Node发生故障，被逐出或刚刚崩溃)时，中央存储中的当前状态应表示该实例发生了故障。 杂物箱是Pod的一部分，因此，如果Pod死了，则没有正在运行的杂物箱来更新中央商店。

解决方案是在实例失败时使用外部代理更新中央存储。 一种方法是执行Pod健康检查。 然后，PostgreSQL控制器可以检查其每个实例的Pod状态，以查看哪些实例发生故障。 在这种模型中，Kubernetes和实例Sidecar共同负责在中央商店中维护实例的当前状态。

PostgreSQL整个应用程序状态

上一节是关于实例级状态的。 在进入应用程序级状态之前，我想解决控制器与实例Sidecar之间的关键区别。

实例死亡时，它将保持死亡状态。 控制器死亡后，将使用新的控制器来代替。

之前，我们可以选择编码实例设置，既可以是从"未完成"到"完成"的单状态转换，也可以是从"未完成"到"步骤1"到"步骤2"到"完成"的多个转换。 之所以存在这种选择，是因为Sidecar不必依赖中央存储中实例的当前状态。 它可以简单地将当前状态保存在内存中。

另一方面，控制器确实依赖中央存储中应用程序的当前状态。 如果控制器死了，则其更换必须能够从中断处继续进行。 例如，考虑故障转移过程：

· 状态：健康(1个主要状态，2个备用状态)→操作：无

· 状态：不正常(0个主要状态，2个备用状态)→操作：将一个备用状态所需的状态设置为"主要"。

· 状态：运行状况良好(1个主数据库，1个备用数据库)→操作：创建一个新的备用数据库

· 状态：健康(1个主要状态，2个备用状态)→操作：无

注意，每个当前状态对应于特定动作(给定特定期望状态)。

如果控制器在步骤2中死亡，则替换控制器会做什么？ 前一个控制器是否执行了该动作？ 如果可以安全地重试该操作(即该操作是幂等的)，则替换控制器可以简单地执行该操作，而不管原始控制器是否执行了该操作。 否则，可能的状态集必须区分这两种情况。

对于上面的步骤2，该操作只是在中央存储区中写入所需的状态。 由于替换控制器可以写入与其前任相同的期望状态，因此该操作可能是幂等的。 另一种方法是在步骤2和3之间添加一个中间状态：

2.状态：不正常(0个主要状态，2个备用状态)→操作：将一个备用状态所需的状态设置为"主要"。

2.5。 状态：不健康(0个主节点，2个备用数据库)，正在等待升级备用数据库1＃→操作：无

3.状态：运行状况良好(1个主数据库，1个备用数据库)→操作：创建一个新的备用数据库

请注意，此方法要求操作和状态更改以原子方式一起发生。 否则，控制器可能会在执行第2步的操作之后并在将状态更新为2.5之前失败。 替换负责人会认为第2步的操作尚未发生。

在此处的示例中，操作是设置实例的所需状态。 如果应用程序的当前状态包括每个实例的所需状态，则操作和状态更改确实会自动发生。 对于其他类型的操作，这将不成立。 最好确保这些动作是幂等的。

还剩什么？

到目前为止，我们已经广泛地介绍了如何在Kubernetes上高度可用的PostgreSQL应用程序中协调PostgreSQL实例的生命周期。 如果您想在特定区域获得更多详细信息，请在评论中告诉我！ 有很多要讨论的内容，所以请帮助我选择下一部分内容。

不过，确保PostgreSQL正在运行并不是我们关注的终点。 我们仍然必须注意可观察性，负载平衡，管理备份存档等。 敬请关注。

(本文翻译自Kynan Rilee的文章《PostgreSQL on Kubernetes the Right Way: Part Three》，参考：https://medium.com/kokster/postgresql-on-kubernetes-the-right-way-part-three-32fbd36942f)