Kubernetes 部署上的 Django：数据库迁移的最佳实践

Question

我的 Django 部署有 x 个 pod（当前 3 个）运行 Django 后端 REST API 服务器。我们仍处于开发/暂存阶段。我想咨询有关数据库迁移的建议。现在，假设数据库已迁移并准备就绪，Pod 只需启动网络服务器即可。这个假设当然可能是错误的。

我可以python manage.py migrate在运行服务器之前简单地放置吗？如果同时启动 2 个或 3 个 Pod 并且所有的 Pod 都在同一时间运行迁移，会发生什么情况？会不会有任何潜在的损害或问题？此处是否有最佳实践模式可确保所有 pod 都使用健康的迁移数据库启动服务器？

我在想这个：

在初始部署期间，定义一个Job将在数据库 pod 准备就绪后运行一次的 Kubernetes对象。它将使用我拥有的相同 Django 容器，并且将简单地运行python manage.py migrate. 部署的脚本将使kubectl wait该作业 pod 完成，然后应用yaml创建完整 Django 部署的脚本。这将确保所有 django pod 使用完全迁移的数据库“唤醒”。

在后续更新中，我将在重新应用 Django 部署 pod 升级之前再次运行相同的作业。

现在有一个关于在迁移过程中保持 100% 正常运行时间的问题，但这是另一篇文章的问题：当用于新迁移的代码更新时，如何应用 BREAK 现有容器版本 X 的数据迁移容器版本 X+1。您是否在更新期间使整个服务脱机？是否有保持服务正常运行的模式？

Answer 1

migrate嗯，您关于多个 pod 启动时将针对您的数据库运行多个命令的部分是正确的。

但这不会造成任何问题。当您要对数据库进行实际更改时，如果更改已应用，则您的更改将被忽略。因此，假设 3 个 pod 同时启动并运行命令migrate。只有One这些命令最终会将更改应用到数据库。迁移通常需要锁定数据库以执行不同的操作（这与您的 DBMS 高度相关）。锁定将由其中一个migrate命令（其中一个 pod）发生，其他命令应等到第一个命令的工作结束。第一个完成工作后，其他人的命令将自动被忽略。所以每次迁移都会发生一次。

但是，您可以更改部署策略并要求 kubernetes 首先仅启动 1 个 pod，当第一个 pod 的运行状况检查成功时，其他 pod 也会启动。在这种情况下，您可以确保迁移的锁定时间只会发生一次，其他人只会检查迁移是否已应用并自动忽略它们。