自建K8s迁移华为云CCE，我们踩过的几个坑

去年我们把一套老业务从自建机房的Kubernetes集群迁移到华为云CCE，前后折腾了三周，踩了不少坑。分享几个印象最深的，给准备做迁移的同行提个醒。

第一个坑：存储类不兼容

我们老集群用的是自建的NFS Provisioner，动态创建PVC时自动分配存储。迁移到CCE后，PVC一直挂不上，报waiting for volume to be created。检查后发现，CCE默认的StorageClass是csi-disk（云硬盘）和csi-nas（文件存储），跟我们的NFS Provisioner完全不兼容。

有两种解法：一是把StatefulSet的存储方案改成云硬盘，二是自己部署一个NFS Provisioner到CCE集群里。我们选择了后者，因为有几套有状态服务对NFS依赖比较重，短期内改造风险大。在CCE集群里重新部署了NFS服务端和Provisioner，然后把StorageClass名字改成跟原来一致，PVC重建后自动绑定，问题解决。

但云硬盘方案后来我们也做了测试，性能比自建NFS好不少，以后新业务会优先考虑。

第二个坑：Ingress Controller冲突

我们老集群用的ingress-nginx，CCE默认提供的是自研的ELB Ingress Controller，通过Ingress资源直接对接华为云的弹性负载均衡。两者不能共存吗？其实可以，但要小心资源冲突。

我们刚开始没注意，按老习惯直接kubectl apply -f ingress.yaml，结果创建出来的Ingress被CCE的Controller接管了，但注解语法不兼容，转发规则完全不生效。看了半天日志才发现默认的IngressClass是cce，而我们老的ingress-nginx的Class是nginx。

解决方案是在Ingress资源里显式指定ingressClassName: nginx，然后确保ingress-nginx的Pod正常运行。同时把用ELB Ingress的规则和新老应用分开，逐步把老应用切到ELB Ingress上，毕竟云原生ELB的稳定性比自建的好很多，而且免运维。

第三个坑：网络插件模式差异

老集群用的是Calico，IPIP模式，跨节点Pod通信走overlay。CCE默认用的网络模型是VPC网络，每个Pod直接分配一个VPC子网内的IP，不走隧道，性能更好。

但问题来了，我们有些应用配置里写死了Pod网段（192.168.0.0/16），老集群的Pod IP就是这个段。到了CCE上，Pod IP变成VPC子网的真实IP（比如10.0.1.x），应用里那些硬编码的IP白名单、对端地址配置全都废了。

改配置是唯一出路，把所有硬编码的IP地址替换成Service域名或者环境变量注入。这个工作量最大，差不多花了五天梳理和测试。教训就是，以后再也不敢把IP写死在配置里了。

第四个坑：日志采集路径变化

老集群里我们用的EFK，日志挂载在宿主机的/var/log/containers目录下，Filebeat采集。CCE推荐的日志方案是云日志服务LTS，通过安装ICAgent采集Pod标准输出和指定路径文件。

本来可以直接用LTS，但我们的日志格式比较特殊，还依赖一些老旧的解析脚本，切换到LTS的采集规则要重新配置解析逻辑。最后折中方案是把日志打到标准输出，用LTS采集stdout，然后通过日志组筛选查看，老脚本暂时保留，后续再改造。

这个坑其实不算技术难题，但涉及多个团队协调（开发和运维对日志格式有分歧），拖了一周才搞定。

总结一下

迁移完回头看，最大的感受是：Kubernetes虽然号称标准化，但每家云厂商在存储、网络、负载均衡这些底层组件上都有差异，不能指望“一键迁移”。提前做调研、在测试环境完整跑一遍流程、做好回滚预案，这三件事缺一不可。