我的 Django 部署有 x 个 pod(当前 3 个)运行 Django 后端 REST API 服务器。我们仍处于开发/暂存阶段。我想咨询有关数据库迁移的建议。现在，假设数据库已迁移并准备就绪，Pod 只需启动网络服务器即可。这个假设当然可能是错误的。
我可以简单地说python manage.py migrate在运行服务器之前？如果同时启动 2 个或 3 个 Pod 并且所有的 Pod 都在同一时间运行迁移，会发生什么情况？会不会有任何潜在的损害或问题？此处是否有最佳实践模式可确保所有 pod 都使用健康的迁移数据库启动服务器？
我在想这个:
在初始部署期间，定义一个 Kubernetes Job将在数据库 pod 准备好后运行一次的对象。它将使用我拥有的相同 Django 容器，并且将简单地运行 python manage.py migrate .部署的脚本将 kubectl wait完成该作业 Pod，然后应用 yaml这将创建完整的 Django 部署。这将确保所有 django pod 使用完全迁移的数据库“唤醒”。
在后续更新中，我将在重新应用 Django 部署 pod 升级之前再次运行相同的作业。
现在有一个关于在迁移过程中保持 100% 正常运行时间的问题，但这是另一篇文章的问题:当用于新迁移的代码更新时，如何应用 BREAK 现有容器版本 X 的数据迁移容器版本 X+1。您是否在更新期间使整个服务脱机？是否有保持服务正常运行的模式？
最佳答案
好吧，您对多个 migrate 的部分是正确的命令将通过多个 pod 启动对您的数据库运行。
但这不会造成任何问题。当您要对数据库进行实际更改时，如果更改已经应用，您的更改将被忽略。因此，假设 3 个 Pod 同时启动并运行 migrate命令。只有 One这些命令的最终将应用更改到数据库。迁移通常需要为不同的操作锁定数据库(这与您的 DBMS 高度相关)。锁定将由 migrate 之一发生命令(其中一个 pod)和其他命令应该等到第一个命令的工作结束。第一个工作完成后，其他人的命令将被自动忽略。所以每次迁移都会发生一次。
但是，您可以更改部署策略并要求 kubernetes 首先启动，仅启动 1 个 Pod，当第一个 Pod 的健康检查成功时，其他 Pod 也会启动。在这种情况下，您可以确保迁移的锁定时间只会发生一次，而其他人只会检查迁移是否已经应用并自动忽略它们。
关于Kubernetes 部署上的 Django : Best practices for DB Migrations，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/60059716/