为什么要做 K8S 迁移？

最近项目上应用往 Kubernetes 迁移进行得如火如荼，经过了长达两周的 Spike，迁移的测试环境总算通过了业务主流程的端到端测试，正式迁移马上开始。

对于容器编排系统来说，项目中已有用了近 2 年的 Rancher，现今运行得非常稳定，哪怕是有些一直没能解决的问题，也有比较快速的 Workaround。项目中的 Dev 和 QA 等角色对 Rancher 的熟练程度也比较高，很多时候出现问题都都能够自行解决，而不需要 Ops 的支持。

整体来看 Rancher 顶好的，已经能够满足当前业务系统的开发、测试和运行。往 Kubernetes 迁移这种事情对现在的业务来说没有太大的价值，反而增加的一些不确定性会带来风险。

那为什么我们需要迁移？抛开 Kubernetes 自身的技术特性外，还有哪些？

顺势而为

在客户规划的 IT 技术栈标准中，Kubernetes 处于 Recommended 状态，并且客户大部分容器化的应用，甚至客户自建的容器云，均以 Kubernetes 为核心构建，而 Rancher 并不在客户规划的技术栈里。

虽然 Rancher 能够承载当前业务系统的运行，但从客户侧的IT规划考量，后续转向 Kubernetes 的可能性几乎为百分之百。虽然技术用得越久，积累的经验越多，应对突发情况的能力也越强，但还有一个重要的问题就是，任何技术在使用过程中会不可避免的产生技术债，使用得越久偿还技术债的成本就越高。既然注定了要迁移，则宜早不宜迟。

所以，需要迁移。

未雨绸缪

在 Kubernetes 赢得编排之战的胜利后，只要是和容器技术相关的，不论企业、团队还是个人，均全面拥抱 Kubernetes 阵营，而在 CNCF 的推动下的 Kubernetes 也成为了容器编排领域的事实标准。

在这个大背景下， RancherLabs 公司也打消了 Rancher 1.0 时代推广自己的编排系统 Cattle 的想法，在 Rancher 2.0 时代直接 All in Kubernetes。

考虑到这个因素，我们正在使用的 Rancher 1.6 在后续很有可能处于一个无维护的状态，一方面是 RancherLabs 公司必然会把精力投向基于 Kubernetes 的发行版 Rancher 2.0，一方面随着社区中使用 Rancher 1.0 的用户也不可避免的逐渐减少。这种情况下一旦发现未遇见过的突发情况，解决问题的成本会非常高。

所以，需要迁移。

放眼未来

Kubernetes 拥有大量的用户群体和落地实践，做为生产环境的编排系统在成熟度和稳定性上已得到业界的认可，很有可能在不久的将来成为云操作系统的内核。

无论是客户还是公司都已经大规模使用 Kubernetes，那么熟练掌握 Kubernetes 的使用是项目组每一位技术人员的必备技能。但光是看书或者实验很难以真正的掌握一门技术，只有在真实的工作中使用起来那才能积累到手的本事。

对于客户来说，希望拥有技术实力强的合作方，能够帮助他们快速解决问题。对于项目组来说，同样希望拥有一只不断进步不断提升的团队，能够更加灵活的响应各种需求。

所以，需要迁移。

---

乍眼看去这种纯技术层面的改进不但没能直接创造业务价值，反而会给业务的运行带来风险，保持稳定不就顶好吗？

当前时代的业务是快速变化的，我们很难以尽可能少的改变来保证系统的稳定，这样无疑从 IT 层面制约了业务的发展。相反，我们需要顺应这种快速变化的趋势，以尽可能多的改变来保证系统的健壮。

从“不求有功但求无过”转向“适应变化持续改进”，稳定是上个时代的产物，健壮才是适应快速变化时代的必备能力。