如何在Kubernetes上部署Spring Boot应用且不修改数据库已有记录

1. 替换Hibernate自动DDL，引入版本化迁移工具 #

• 生产环境必须将spring.jpa.hibernate.ddl-auto设为none，Hibernate的自动DDL逻辑不可控，极易出现误删字段、修改约束等操作导致数据丢失，完全不适合生产迭代场景。
• 统一使用Flyway/Liquibase这类专业迁移工具管理所有schema变更：
  • 所有变更都转化为可版本控制的脚本，每一次变更对应唯一的版本号，工具自动记录已执行的脚本，避免重复执行冲突。
  • 所有已提交的迁移脚本禁止修改，新变更只能新增更高版本的脚本，保证所有环境的schema变更逻辑完全一致。
  • 所有变更脚本必须满足向前兼容：新增字段必须允许为空或设置合理默认值，禁止直接删除字段/表，废弃字段先标记为废弃，确认无业务依赖后再在下个迭代清理。

2. Kubernetes部署流程解耦与顺序控制 #

• 2.1 迁移动作独立为K8s Job #

  不要把迁移逻辑耦合在应用启动逻辑里，把数据库迁移做成独立的K8s Job资源，执行顺序严格遵循：前置校验 -> 执行迁移Job -> Job成功校验 -> 滚动更新应用Pod，可以通过Init Container或者GitOps工具的前置钩子实现这个顺序控制，确保schema变更完成后才会启动新版应用。

• 2.2 数据库权限最小化隔离 #

  • 迁移Job使用单独的数据库账号，仅授予DDL操作权限；应用运行时账号只分配DML权限（SELECT/INSERT/UPDATE/DELETE），从权限层面避免应用代码误修改schema。
  • 如果你是用Kompose从docker-compose转换配置，注意把原docker-compose中的数据库数据卷对应转换为K8s的PersistentVolumeClaim（PVC），确保数据库数据不会随Pod重建丢失。

• 2.3 滚动更新兼容配置 #

  应用Deployment配置滚动更新策略，合理设置maxSurge和maxUnavailable参数，保证新旧版本应用共存的过渡阶段，两套代码都能兼容当前schema版本：

  所有不兼容变更（比如修改字段名、修改字段类型）必须分多步完成：第一步新增字段，双写新旧字段，第二步确认所有流量都切到新字段后，再下线旧字段，避免单次变更出现兼容性问题。

3. 数据安全兜底机制 #

• 每次执行schema变更前必须做全量备份：PostgreSQL可以用pg_dump做逻辑备份，也可以配合K8s的CSI快照功能做存储卷瞬时快照，一旦变更出现问题可以在分钟级回滚恢复。
• 所有变更脚本必须经过代码审核，提前在预发环境用和线上同量级的数据验证变更性能，涉及大表（百万行以上）的变更要使用无锁语法，比如PostgreSQL的CREATE INDEX CONCURRENTLY，避免锁表导致业务不可用。
• 禁止直接在生产库执行未验证的SQL脚本，所有变更操作都要留好执行日志，便于问题排查。

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