Kubernetes滚动部署和数据库迁移

Question

使用数据库迁移处理滚动更新时，kubernetes如何处理此问题？

对于一个实例 - 我有一个应用程序从app-v1更新到app-v2，其中包括一个用于更改现有表的迁移步骤。所以这意味着它要求我在部署后为rails app运行类似descendant的内容。

在3副本集上进行滚动部署时。它将从一个pod部署到另一个pod。可能允许没有新版本应用程序的POD中断。

虽然这种情况不是经常发生的事情。它很可能会。我想了解这种情况的最佳/推荐方法。

Answer 1

防止旧版本破坏的一种方法是将迁移拆分为多个步骤。

E.g。您想要重命名数据库中的列。直接重命名列会破坏应用程序的旧版本。这可以分为多个步骤：

• 添加插入新列的数据库迁移
• 更改应用，以便所有写入转到旧列和新列
• 运行将所有值从旧列复制到新列的任务
• 更改从新列中读取的应用
• 添加删除旧列的迁移

不幸的是，这很麻烦，但可以防止维护页面停机。

Answer 2

Kubernetes本身不会使用db迁移本地处理滚动更新。这是特定于应用程序的，因此应用程序开发人员必须处理它。您可能必须执行与非k8s设置相同的操作。

无论如何，我这样做的方式是：

• 将副本扩展为1.
• 更新图片。
• 将副本扩展为3。

这不是万无一失的，但不涉及代码更改。 db：migrate步骤和实际服务器侦听之间有一个小窗口，其中请求将转到较旧的副本（一旦新副本准备就会终止）。该请求可能会失败，也可能不会失败，具体取决于代码块是否与架构更改直接相关。

如果我不太关心停机时间，那么我只会使用重新创建策略。

Answer 3

我最近解决了这个问题，这是我的方式：

• 使用deployment annotations存储在部署之前或之后通常需要运行的命令。
• 创建一个脚本，该脚本能够按名称读取您的部署，然后创建一个作业来运行部署注释中指定的命令。
• 将图像推送到docker注册表时，添加一个webhook，它将调用上一点中指定的脚本。
• 为避免数据库结构不兼容问题：
  • 不要以向后不兼容的方式修改db列。
  • 请勿在迁移中立即删除未使用的列。您可以在下一个版本中执行此操作。这样你就只有一个 您将在部署之前运行的迁移脚本。

P.S。为了能够在您的脚本中使用Kubernetes，您可能希望熟悉以下链接：Kubernetes API，Kubernetes API Overview，Access Clusters Using the Kubernetes API，Client Libraries。