云原生化的迁云实战

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 云原生的时代已经到来,云原生技术正在重塑整个软件生命周期,阿里巴巴是国内最早布局云原生技术的公司之一。 容器服务团队在过去的几年时间内帮助很多用户成功把业务云原生化并迁移上云,其中有现在已经是我们TOP10的大客户,也有需要在国内开展业务的海外用户,有些是从其他云厂商迁移过来的用户,有些是从IDC里迁移上云的用户,而且越来越多的用户开始咨询如何对自己的应用做云原生化改造、如何把业务平滑地迁移到云上。

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

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

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

image

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

image

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

image

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

2. 整体迁云方案设计

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

image

迁云到ACK需要做涉及到哪些组件、搬迁哪些数据、切换哪些服务等,都是需要用户又清晰的概念的。首先需要做集群规划,用户需要根据自己业务场景的不同来选择不同的机器类型,比如CPU机器还是GPU机器,比如虚拟服务器ECS还是神龙裸金属服务器等等,网络规划这部分会涉及到容器集群基础设施选择vpc内网网络还是经典网络,集群内pod之间进行通信模式是flannel模式还是terway模式等,在容量规划这部分,用户可以根据自己的成本以及预算规划一个可满足初期业务正常运行的容量即可,随后可以配置动态扩缩容随时弹缩集群规模;在安全防护提升这部分,有基础架构安全比如设置合理的安全组规则,有镜像安全比如使用私有镜像并定义镜像安全扫描,K8S应用安全管理比如设置不同服务间互相访问的网络安全策略等;监控切换这部分相对于用户自建Kubernetes会更加全维度和立体,从基础设施到容器运行时监控一应俱全,并可根据阈值设定触发报警通知;用户一般也会把自建的日志收集方案切换成阿里云上企业级的日志产品SLS;数据迁移是非常重要的一部分,这些数据包括数据库数据、存储数据、容器镜像等,我们会对接阿里云上企业级的粗出产品以及迁移工具,目的是为了保证数据迁云的可靠性、安全性;应用改造主要涉及的内容包括镜像地址的更新、服务暴露方式的优化以及存储盘挂载方式的更新适配;最后提供一个满足用户快速迭代上线产品的CICD方案。以上各个组件调试完毕后,我们就可以进行一部分生产流量的切换。以上从集群规划到生产流量切换便是用户业务迁移上云所需要涉及到的方方面面。

image

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

image

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

image

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

image

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

Velero迁移Kubernetes应用到ACK视频DEMO

image

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

image

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

3. 应用改造和优化

image

image

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

image

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

4. 案例

image

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

5. 总结

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

相关实践学习
通过容器镜像仓库与容器服务快速部署spring-hello应用
本教程主要讲述如何将本地Java代码程序上传并在云端以容器化的构建、传输和运行。
Kubernetes极速入门
Kubernetes(K8S)是Google在2014年发布的一个开源项目,用于自动化容器化应用程序的部署、扩展和管理。Kubernetes通常结合docker容器工作,并且整合多个运行着docker容器的主机集群。 本课程从Kubernetes的简介、功能、架构,集群的概念、工具及部署等各个方面进行了详细的讲解及展示,通过对本课程的学习,可以对Kubernetes有一个较为全面的认识,并初步掌握Kubernetes相关的安装部署及使用技巧。本课程由黑马程序员提供。   相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
3月前
|
运维 Cloud Native Devops
一线实战:运维人少,我们从 0 到 1 实践 DevOps 和云原生
上海经证科技有限公司为有效推进软件项目管理和开发工作,选择了阿里云云效作为 DevOps 解决方案。通过云效,实现了从 0 开始,到现在近百个微服务、数百条流水线与应用交付的全面覆盖,有效支撑了敏捷开发流程。
19351 30
|
6月前
|
Kubernetes Cloud Native 应用服务中间件
云原生|kubernetes 你真的学废了吗---实战k8s 一(jsonpath实战)
云原生|kubernetes 你真的学废了吗---实战k8s 一(jsonpath实战)
131 1
|
2月前
|
运维 Cloud Native Docker
云原生技术入门:Docker容器化实战
【9月更文挑战第20天】本文将引导你走进云原生技术的世界,通过Docker容器化技术的实战演练,深入理解其背后的原理和应用。我们将一起探索如何在云平台上利用Docker简化部署、扩展和管理应用程序的过程,并揭示这一技术如何改变现代软件的开发和运维模式。
|
3月前
|
Kubernetes Cloud Native Docker
云原生入门:Docker容器化部署实战
【8月更文挑战第31天】在数字化浪潮中,云原生技术成为企业转型的助推器。本文通过Docker容器化部署的实践案例,引导读者从零基础到掌握基础的云原生应用部署技能。我们将一起探索Docker的魅力,学习如何将一个应用容器化,并在云平台上运行起来,为深入云原生世界打下坚实基础。
|
4月前
|
Kubernetes Cloud Native 微服务
企业级容器部署实战:基于ACK与ALB灵活构建云原生应用架构
这篇内容概述了云原生架构的优势,特别是通过阿里云容器服务Kubernetes版(ACK)和应用负载均衡器(ALB)实现的解决方案。它强调了ACK相对于自建Kubernetes的便利性,包括优化的云服务集成、自动化管理和更强的生态系统支持。文章提供了部署云原生应用的步骤,包括一键部署和手动部署的流程,并指出手动部署更适合有技术背景的用户。作者建议在预算允许的情况下使用ACK,因为它能提供高效、便捷的管理体验。同时,文章也提出了对文档改进的建议,如添加更多技术细节和解释,以帮助用户更好地理解和实施解决方案。最后,展望了ACK未来在智能化、安全性与边缘计算等方面的潜在发展。水文一篇,太忙了,见谅!
|
6月前
|
Cloud Native 测试技术 数据库
【云原生之Docker实战】使用Docker部署flatnotes笔记工具
【5月更文挑战第17天】使用Docker部署flatnotes笔记工具
238 8
|
6月前
|
Cloud Native 关系型数据库 分布式数据库
【PolarDB开源】PolarDB数据迁移实战:平滑过渡至云原生数据库
【5月更文挑战第24天】本文介绍了如何平滑迁移数据至阿里云的云原生数据库PolarDB,包括迁移准备、策略选择、步骤、验证及示例代码。通过需求分析、环境准备和数据评估,选择全量、增量或在线迁移策略。使用数据导出、导入及同步工具(如DTS)完成迁移,并在完成后验证数据一致性、性能和安全。正确执行可确保业务连续性和数据完整性。
217 1
|
6月前
|
存储 弹性计算 Kubernetes
【阿里云云原生专栏】深入解析阿里云Kubernetes服务ACK:企业级容器编排实战
【5月更文挑战第20天】阿里云ACK是高性能的Kubernetes服务,基于开源Kubernetes并融合VPC、SLB等云资源。它提供强大的集群管理、无缝兼容Kubernetes API、弹性伸缩、安全隔离及监控日志功能。用户可通过控制台或kubectl轻松创建和部署应用,如Nginx。此外,ACK支持自动扩缩容、服务发现、负载均衡和持久化存储。多重安全保障和集成监控使其成为企业云原生环境的理想选择。
482 3
|
6月前
|
监控 安全 Cloud Native
【云原生之Docker实战】使用Docker部署Ward服务器监控工具
【5月更文挑战第11天】使用Docker部署Ward服务器监控工具
214 4
|
6月前
|
Cloud Native 安全 Linux
【云原生之Docker实战】使用Docker部署mBlog微博系统
【5月更文挑战第10天】使用Docker部署mBlog微博系统
152 3