代表|以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。
【 代表|以Kubernetes为代表的容器技术，已成为云计算的新界面】
过程中，阿里引入 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 的演进