云原生化的迁云实战

31次阅读

共计 3330 个字符,预计需要花费 9 分钟才能阅读完成。

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

容器服务团队在过去的几年时间内帮助很多用户成功把业务云原生化并迁移上云,其中有现在已经是我们 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. 案例

接下来是部分迁云案例,有对高性能网络有特殊需求的用户,有做深度学习相关业务对大规模 GPU 机器有需求的用户,有要求裸金属机型服务器的用户等等。

5. 总结

不同用户的不同业务场景在云原生化迁云方案的设计和落实上都有各自的差异性,不尽相同,需要结合 ACK 团队沉淀下来的最佳实践来快速做出评估和计划,并借助已有的一系列迁云工具快速完成业务从线下迁移上云的过程。


本文作者:流生

阅读原文

本文为云栖社区原创内容,未经允许不得转载。

正文完
 0