Django本地修改模型后如何同步K8s部署的MariaDB变更

核心结论先明确 #

首先直接回答你第二个问题：本地执行完manage.py makemigrations和manage.py migrate就直接重新部署Django应用，完全解决不了问题。
原因很简单：你本地跑migrate的时候连的是本地配置的数据库，和K8s集群里的MariaDB网络完全不通，根本碰不到集群里的库表；而且Django应用本身启动时不会自动执行迁移命令，就算你把新代码打包部署上去，没有主动触发连接集群数据库的迁移操作，表结构永远不会变。
另外makemigrations只是生成对应的表结构变更脚本文件，这个文件是跟着代码走的，你需要把生成的migrations文件提交到代码仓库，打包进新的Django镜像里，这步是对的，但本地执行migrate对集群数据库没有任何意义。 #

集群内MariaDB同步模型变更的标准操作步骤 #

整个流程和你本地操作的逻辑完全一致，区别只在于migrate命令必须在能直连集群内MariaDB的环境下执行，按以下步骤走即可：

• 第一步：本地修改完models.py后，只执行python manage.py makemigrations，不要在本地执行migrate。检查生成的migrations脚本逻辑（比如新增字段有没有设置合理的默认值、是否允许为空，避免执行时锁表影响业务），确认无误后把migrations文件提交到Git仓库，走正常构建流程打包含最新代码的Django应用镜像。
• 第二步：选择以下任意一种方式执行migrate命令，所有方案的核心要求都是执行命令的环境能通过集群内网访问到MariaDB服务：
  • （生产环境最推荐）在CD部署流水线中添加前置K8s Job：用和Django应用完全一致的最新镜像，配置和应用完全相同的数据库环境变量（MariaDB服务地址、账号、密码、库名，直接用同一命名空间下的MariaDB Service域名即可），执行python manage.py migrate命令。等Job执行成功、确认迁移无报错后，再触发Django Deployment的滚动更新。这个方案能保证代码版本和表结构严格匹配，不需要手动登录集群操作，出错概率最低。
  • （测试/临时调试适用）用kubectl启动临时Pod执行迁移：直接在本地终端执行命令，用你打好的最新Django镜像起一个一次性临时Pod，跑完迁移自动销毁：

    kubectl run -it --rm django-migrate-job \
      --image=<你的最新Django镜像地址> \
      -n <Django和MariaDB所在的命名空间> \
      -- python manage.py migrate
    

  • （仅快速验证适用，不推荐生产用）端口转发本地执行：通过kubectl port-forward svc/<mariadb的service名> 3306:3306 -n <命名空间>把集群内MariaDB的端口转发到本地，临时修改本地Django配置的数据库地址为127.0.0.1，再在本地执行python manage.py migrate。这个方案需要你本地有集群的操作权限，生产环境用存在安全风险。
• 第三步：确认migrate所有操作执行无报错后，再把Django应用滚动更新到最新镜像版本，保证运行中的应用代码和表结构完全匹配，避免启动报错。

注意：如果是百万级以上数据量大表加字段，提前评估DDL锁表风险，避开业务高峰执行迁移，必要时可以用第三方无锁迁移工具配合Django的migrate --fake参数做零停机变更，不要直接硬上导致业务雪崩。

内容的提问来源于stack exchange，提问作者Varshini