云原生化的迁云实战

云原生的时代已经到来，云原生技术正在重塑整个软件生命周期，阿里巴巴是国内最早布局云原生技术的公司之一。

容器服务团队在过去的几年时间内帮助很多用户成功把业务云原生化并迁移上云，其中有现在已经是我们TOP10的大客户，也有需要在国内开展业务的海外用户，有些是从其他云厂商迁移过来的用户，有些是从IDC里迁移上云的用户，而且越来越多的用户开始咨询如何对自己的应用做云原生化改造、如何把业务平滑地迁移到云上。每个用户的业务场景都是不同的，有些差异化的业务场景对容器平台也有一些定制化的需求，我们在帮助这些用户落实迁云方案的同时也在不断思考如何把这些案例中共性的东西做一些沉淀，总结出一些优秀的解决方案、最佳实践以及开发一些工具来帮助用户快速完成迁云的这件事情。这些解决方案、最佳实践以及迁云工具就是今天这篇文章想要分享的内容。

在帮助用户落实迁云方案之前，我们首先必须要回答至少3个问题：（1）ACK（阿里云容器服务Kubernetes）如何能保证用户业务的可靠性、稳定性、安全性和灵活性；（2）如何设计迁云方案把业务平滑地迁移到ACK；（3）应用如何做进一步改造来适配ACK提供的更强大的扩展能力。

1. ACK如何保证用户业务的可靠性、稳定性、安全性和灵活扩展性

首先，ACK是以阿里云可靠稳定的IaaS平台为底座的，有最大的弹性化与低廉成本和全球化接入的优势；其次，ACK本身处于阿里云的安全体系架构之下并从基础设施到容器运行时环境对容器集群有全维度的安全加固；过去几年我们很好地支撑了成百上千家大小企业的业务运行，有海量用户经验总结并经过双11验证；除此之外。ACK是在标准的Kubernetes基础上，对与用户息息相关的能力做了大幅提升，用户完全不需要担心会被某一家厂商绑定。

在我们过去帮助用户业务上云的案例中，绝大部分是自建Kubernetes集群迁移到ACK集群，与自建Kubernetes集群相比较，ACK在成本、弹性、IaaS高度融合、性能、安全加固以及实践经验等方面都有非常巨大的优势。

另外，ACK与阿里云的所有region保持一致，除了国内多个区域开服外，在东南亚、中东、欧洲、美东美西都有开服，完全可以满足用户开展全球业务的需求。

2. 整体迁云方案设计

用户业务整体迁云的方案设计会涉及到集群规划、数据搬迁、监控切换、日志切换以及最终的生产流量切换或并网操作。

迁云到ACK需要做涉及到哪些组件、搬迁哪些数据、切换哪些服务等，都是需要用户又清晰的概念的。首先需要做集群规划，用户需要根据自己业务场景的不同来选择不同的机器类型，比如CPU机器还是GPU机器，比如虚拟服务器ECS还是神龙裸金属服务器等等，网络规划这部分会涉及到容器集群基础设施选择vpc内网网络还是经典网络，集群内pod之间进行通信模式是flannel模式还是terway模式等，在容量规划这部分，用户可以根据自己的成本以及预算规划一个可满足初期业务正常运行的容量即可，随后可以配置动态扩缩容随时弹缩集群规模；在安全防护提升这部分，有基础架构安全比如设置合理的安全组规则，有镜像安全比如使用私有镜像并定义镜像安全扫描，K8S应用安全管理比如设置不同服务间互相访问的网络安全策略等；

监控切换这部分相对于用户自建Kubernetes会更加全维度和立体，从基础设施到容器运行时监控一应俱全，并可根据阈值设定触发报警通知；用户一般也会把自建的日志收集方案切换成阿里云上企业级的日志产品SLS；数据迁移是非常重要的一部分，这些数据包括数据库数据、存储数据、容器镜像等，我们会对接阿里云上企业级的粗出产品以及迁移工具，目的是为了保证数据迁云的可靠性、安全性；应用改造主要涉及的内容包括镜像地址的更新、服务暴露方式的优化以及存储盘挂载方式的更新适配；最后提供一个满足用户快速迭代上线产品的CICD方案。以上各个组件调试完毕后，我们就可以进行一部分生产流量的切换。以上从集群规划到生产流量切换便是用户业务迁移上云所需要涉及到的方方面面。

我们提供了一个企业容器化生命周期模型，这个模型是根据时间阶段和用户侧各个业务角色来划分的，比如业务架构师角色需要关心的是业务上云能给公司带来什么价值，在TCO和场景上会带来哪些优化，云平台在安全性以及计算、存储、网络能力上是否能满足当前业务需求；IT架构师负责规划当前业务需要的集群容量和规模以及网络选型等问题，剩下的就是系统管理员与应用管理员把迁云方案的各个细节落实下来。这个模型的主要核心关注点是让用户的业务上云后能更稳定、成本更低、效率更高。

全栈迁云架构思路分两种，一种是整体迁移，一种是平滑迁移。整体迁移是指用户应用全部迁移上云后，各个组件调试完毕、测试验收通过后，可以整体切换生产流量到线上集群，待线上集群上的业务稳定运行一段时间后再下线原有环境。平滑迁移是指用户可以使用线上ACK集群纳管线下节点，或者线上集群与线下集群混合组网对外提供服务，逐步改造业务组件上云后将原有环境下线。这两种方式相比，整体迁移更简单，平滑迁移响度复杂但对业务影响小，所以也需要根据用户的实际场景做选择。

容器化整体迁云这部分还有两个小场景，一个是用户从自建Kubernetes集群迁移到ACK，此场景下用户的应用已经做了很大一部分的云原生化改造，迁移工作相对来说会简单些，还有一部分用户的应用是传统应用，直接运行在虚拟机或者裸金属服务器上，没有做过任何云原生化的改造，对于这部分场景，我们也提供了相关工具或方案帮助用户进行云原生化的迁云改造，比如使用derrick项目可以自动检测源码项目类型并生成Dockerfile和用于应用部署编排的yaml文件，比如我们正在联合ECS SMC（迁云中心）开发的虚拟机转换容器镜像并运行在ACk集群中的能力。

为了帮助用户提高迁云的效率，我们也在持续积累和开源一些迁云工具。比ack-image-builder为用户提供创建ACK集群节点自定义镜像的模板并通过校验模块检查自定义镜像是否满足ACK集群要求；sync-repo能够帮助用户快速完成容器镜像批量迁移至ACR（容器镜像仓库服务）; velero能够帮助用户快速把其他云厂商后者自建Kubernetes集群下的完整应用迁移至ACK集群。

Velero迁移Kubernetes应用到ACK视频DEMO

在数据搬迁部分，可靠迁移是关键，根据用户数据类型的不同，我们会使用与之匹配的企业级迁移工具，比如数据在线迁移服务DOMS，比如OSS的迁移工具，还有离线海量数据迁移方案闪电立方等。

数据、应用迁云完成后，需要进一步适配监控、日志等组件，待各个组件调试完毕通过验收后，可以使用智能DNS进行生产流量的切割。

3. 应用改造和优化

对于应用改造和优化这部分，K8s到K8s的场景下，需要优化的是去适配自动扩容等自建K8s不具备的那些能力，在传统应用迁移到ACK的场景下，这部分的工作量会更大些，所以我们针对这个场景也输出了一些方案，比如类似于异地多活的方案，我们把用户传统应用环境，通常是虚拟机或者裸机环境集成到线上ACK部署的Istio网格中，逐步改造应用直至业务全部切换到线上ACK集群。

在应用逐步改造的这个过程中，会涉及到应用如何容器化、网络环境如何迁移以及数据迁移的问题，应用容器化这个问题，我们可以使用前面我提到过的一个服务叫做SMC迁云中心来完成虚拟机转换为容器镜像的过程，网络这部分可以通过iptables，External，CoreDNS PrivateZone等方式对IP地址DNS域名做处理，保持原先的逻辑IP和域名不变，并通过Istio实现网络虚拟路由和可观测性的管理。

4. 案例