云原生容器新界面崛起 阿里云引领云原生发展

在节点资源层,用户可充分利用 Kubernetes 的底座扩展能力,让节点管理实现云原生化;在架构层面,通过节点生命周期控制器、自愈控制器和组件升级控制器等,可实现节点自愈、流转、交付、环境组件变更的节点生命周期的完全闭环,让容器层完全屏蔽底层节点感知,完全改变了节点的运维管理模式。基于强大的云原生节点管理模式,阿里巴巴内部将集团之前相对割裂的节点资源整合为一体,真正实现了资源池从点形成面,将内核、环境组件、机型规格等进行统一标准整合,资源池的大一统并结合统一调度形成巨大的弹性能力,这也是云原生节点管理中的『书同文,车同轨,度同制,行同伦,地同域』,让节点资源从诸侯格局变成了大一统的云原生资源池。

新兴的生态和业务,基于 ACK(阿里云容器服务)提供的云原生土壤,如 Service Mesh、Serverless、Faas 等,也非常快速地在集团内落地,并得到蓬勃发展。

在应用 PaaS 层,云原生的应用交付模式走向了更为彻底的容器化,充分利用了 Kubernetes 的自动化调度能力,基于 OAM Trait 的标准定义来构建集团内统一的 PaaS 运维能力,基于 GitOps 研发模式让基础设施和云资源代码化、可编程。

阿里集团向云原生容器界面的演进

为了支撑阿里集团庞大而复杂的业务,十年之间,众多技术工程师走出了一条深深浅浅的容器之旅。

那么,在阿里集团内部,容器界面是如何演进的呢?

在过去十年,阿里集团内的容器技术,经历了从自研 LXC(Linux Container)容器 T4,到富容器,再到 Kubernetes 云原生轻量级容器的演进历程。每一次转变升级,都是基于不同时期的业务背景,所做出的技术迭代和自我革新。

第一阶段:基于 LXC 的容器 T4 尝试

受困于虚拟机 KVM 的巨大开销,以及 KVM 编排管理的复杂度,阿里集团在 2011 年时发起对 LXC 和 Linux Kernel 的定制,在内部上线了基于 LXC 的 T4 容器。但相比后面出现的 Docker, T4 容器在技术上存在一些不足,比如没有实现镜像提取和应用描述。T4 诞生后的多年,阿里持续尝试在 T4 之上构建复杂的基线定义,但屡屡遭遇问题。

第二阶段:引入容器镜像机制的 AliDocker,实现大规模分发

2015 年,阿里引入 Docker 的镜像机制,将 Docker 和 T4 的功能取长补短互相整合,即:让 T4 具备 Docker 镜像能力,同时又让 Docker 具备了 T4 对内部运维体系的友好性,并在此基础上形成内部产品 AliDocker。

过程中,阿里引入 P2P 镜像分发机制,随着电商核心应用逐步全面升级到 AliDocker,通过宿主机的环境隔离性和移植性,屏蔽了底层环境差异,为云化/统一调度/混部/存储计算分离等后续基础架构变革打下了基础,镜像机制的优势得以体现。其中,孵化的 P2P 镜像分发是 2018 年 10 月加入 CNCF 的 Dragonfly。

第三阶段:完全自主产权的容器 Pouch,阿里内部全面容器化

随着容器技术的规模化铺开,AliDocker 化的优势得以体现,阿里完全自主产权的 Pouch 得以展开并逐渐替代 AliDocker。同时,阿里集团 100% Pouch 化也一直在快速推进,2016 年 双11 前,已经实现了全网的容器化。

Pouch 寓意是一个神奇的育儿袋,为里面的应用提供贴心的服务。因为 Pouch 统一了集团在线应用的运行时,应用开发人员就无需关注底层基础设施的变化。接下来的数年,底层基础设施发生了云化、混部、网络 VPC 化、存储无盘化、内核升级、调度系统升级等各种技术演进,但 Pouch 容器运行时使绝大部分底层变化对应用无感知,屏蔽了对上层应用的影响。Pouch 自身也把运行时从 LXC 切换到了 runC,并将其核心技术反哺给开源社区,同时集团也逐步将过去的存量 AliDocker 实例无缝切换为开源的 Pouch 实现。

过程中富容器模式的存在,一方面让用户和应用能够无缝平滑地切换到容器化,另一方面应用依赖的各种运维、监控、日志收集等运维系统,基于富容器模式也得以跟随容器化平滑迁移。

但富容器也有着较多缺点。由于富容器中可以存在多个进程,并且允许应用开发和运维人员登录到容器中,这违反了容器的“单一功能”原则,也不利于不可变基础设施的技术演进。例如:Serverless 演进过程中,调度插入的代理进程实际上是与应用无关的,一个容器中有太多的功能也不利于容器的健康检查和弹性。

容器化是云原生的必经之路。阿里集团正是通过这种方式,快速走完了容器化这一步,极大加速了云原生的进一步演进。全面容器化后,云原生的大势已经不可阻挡,越来越多新的理念和应用架构在容器生态中成长起来,基于容器和镜像的应用打包、分发、编排、运维的优势被越多的人看到、接受和拥抱,各种运维系统开始适配云原生架构。

第四阶段:调度系统兼收并蓄及 ACK 的演进

随着以 Kubernetes 为代表的容器技术成为云计算的新界面,阿里自研的 Sigma 也在持续探索 Kubernetes 的落地实践,并借助集团全面上云的契机,最终实现了从 Sigma 管控到 ACK 的全面迁移。

2018 年,集团调度系统开始了从内部定制的 Sigma 到 ACK 的逐步演进,容器轻量化成为一个重要的演进目标。云原生浪潮下,集团内部的运维生态也随之快速演进。轻量化容器的解决思路是用 Kubernetes 的 Pod 来拆分容器,剥离出独立的运维容器,并将众多与应用无关的运维进程逐个转移至运维容器。

Sigma 诞生之初致力于将阿里集团众多割裂的在线资源池整合统一,在此基础上,不断探索新的资源混跑形态,包括在离线混部、离在线混部、Job 调度、CPUShare、VPA 等众多技术。通过提升阿里集团数据中心整体资源利用率,带来巨大的成本节约效益。基于全托管免运维 Sigma Master、公共大资源池、应用额度服务,提供 Serverless 的资源交付和最佳的用户体验。Sigma 调度也加速了 T4 到 Pouch 的全面容器化进程,通过应用研发自定义的 Dockerfile 标准化容器,以及透明化基础设施的 Sigma 调度引擎,业务研发已无需关心底层运维,工作重心得以聚焦于业务本身。

从 Sigma 到 ACK 的升级,是希望 ACK 领先的云产品能力得以赋能阿里集团,使得 Sigma 可以加速享受云计算的能力,包括异构资源的统一管理、面向全球化的安全合规等。但实际上,迁移 ACK 的过程并非一帆风顺:

首先,围绕着核心管控链路,阿里原有的规模和复杂场景能力、原有的庞大存量容器如何迁移到新的平台,以及容器界面如何兼容并影响现有的庞大生态体系升级,实际上都会成为演进中的包袱和劣势。实现在高速飞行中换引擎并解决存量迁移问题的难度,这在业界都有共鸣。

其次,性能、多集群运维、安全防御、稳定性等众多问题,都是全面迁移 ACK 的挑战。围绕着性能,阿里基于原生 Kubernetes 做了非常多的优化并回馈给社区,如 Cache Index、Watch Bookmark 等,并建设了一整套 Kubernetes 规模化设施,包括安全防御组件、OpenKruise、多集群组件发布等能力等。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!