Kubernetes集群迁移的本质是迁移声明式资源模型（KRM），而非镜像或数据卷；需通过KRM函数清洗资源、校验依赖、转换配置，再在新集群重放，确保期望状态一致。
Go语言本身不直接参与Kubernetes集群间的数据迁移——它只是你可能用来编写迁移工具、控制器或Job逻辑的编程语言。真正执行迁移的是Kubernetes原生机制（如pv-migrate）、声明式资源模型（KRM）或数据库专用工具（如golang-migrate/migrate）。关键在于：别让Go“扛数据”，而要让它“调度逻辑”“校验状态”“驱动流程”。
用 golang-migrate/migrate 做跨集群数据库结构迁移
当你的Go应用依赖MySQL/PostgreSQL，且数据库随服务部署在RKE或自建K8s中，结构变更必须跨集群同步。此时golang-migrate/migrate不是跑在本地，而是作为Kubernetes Job运行在目标集群内。
- 迁移脚本必须放在容器镜像里（例如挂载ConfigMap或打包进镜像），不能靠本地文件路径
- Job的
env需显式传入数据库连接信息，避免硬编码；建议用Secret挂载DB_URL - 务必设置
backoffLimit: 0和restartPolicy: Never，防止失败后反复重试污染数据库 - 版本号推荐用时间戳（如
1620000000_add_users_table.up.sql），避免多团队协作时整数冲突 - 注意RKE环境中kube-dns或CoreDNS解析范围——如果Job连不上另一集群的DB，不是网络问题，很可能是Service DNS没跨命名空间暴露
用 pv-migrate 迁移有状态应用的PV数据
pv-migrate是Go写的CLI工具，但它的核心价值不在语言，而在对CSI接口的封装。它把PVC迁移抽象成“源读+目标写+校验”，绕过应用层直接操作底层存储。
- 源PVC必须处于
Bound且应用已停止写入（kubectl rollout pause deploy/mysql比删Pod更安全） - 目标PVC的
storageClassName可以不同，但CSI驱动必须支持Clone或VolumeSnapshot能力（查kubectl get csidriver -o wide） - 不要用
rsync或tar手动复制/var/lib/mysql——文件锁、inode硬链接、SELinux上下文全会丢 - 迁移大体积PV时，加
--progress参数看实时吞吐，避免误判卡死；超时默认1h，可传--timeout=4h - 迁移完成后，用
kubectl exec进新Pod验证ls -l /var/lib/mysql权限是否匹配（尤其注意uid/gid，MySQL容器常以非root用户运行）
用自定义KRM函数清洗跨集群YAML资源
如果你用Go写KRM函数（比如transform-namespace或inject-env），本质是在做资源清单的声明式转换。这不是“迁移数据”，而是确保资源模型能在新集群里被正确解释。
立即学习“go语言免费学习笔记（深入）”；
- KRM函数必须接收
io.Reader输入、输出io.Writer，不能依赖本地文件系统路径 - 别在函数里调用
kubectl get——KRM管道是离线的，所有依赖资源需提前注入inventory对象 - 处理
ConfigMap和Secret时，注意base64编码：KRM默认不解码data字段，你要自己base64.StdEncoding.DecodeString() - 跨云迁移时，
StorageClass名几乎必然不一致，KRM函数得支持映射表（如{"gp2": "premium_lrs"}），否则PVC永远Pending - 函数返回非零退出码会被KRM管道中断，但错误信息不会自动打印到kubectl日志里——务必用
log.Printf写stderr，否则排查无从下手
最易被忽略的一点：Kubernetes迁移里90%的数据问题，根源不在工具链，而在资源间的隐式依赖。比如一个Deployment引用了ConfigMap，而该ConfigMap又写了旧集群的etcd地址——这种“数据中的数据”，任何自动化工具都不会主动识别，只能靠KRM函数扫描data字段正则匹配，或人工review清单diff。
