阿里云ECI如何6秒扩容3000容器实例？

引言

根据最新CNCF报告，有超过90%的用户在生产环境使用容器，并且有超过80%的用户通过Kubernetes管理容器。是不是我们的生产环境上了K8s就完美解决了应用部署的问题？IT界有句俗语，没有什么是万能的，K8s也不是万能的，K8s解决了应用的编排和调度，但没有解决资源容量的限制、没有解决容器的安全隔离，以及高昂的运维成本。

传统K8s的问题和困境

资源效率低

这个资源柱状图来自阿里云一个客户，业务的流量高峰期CPU大概在7000-8000核，在流量低谷期只有几百核CPU的使用。如果在做IT规划或者购买资源时，按照峰值流量去规划资源，会导致严重的资源浪费。但如果按照使用量去实时规划ECS资源，又会导致在面对一些突发流量时无法及时扩容，影响服务的稳定性。

资源隔离弱

容器使用系统内核的namespace进行资源隔离，但内核仅支持UTS、IPS等6种namespace隔离。我们遇到过一个客户，需要在测试环境修改某个业务Docker的时间，结果导致一台机器上所有的容器时间都被修改。还有定制内核参数、IO公平分享等场景，也有相同的问题。

同时，容器安全也一直被大家诟病，例如特权容器直接可以看到机器上所有的磁盘数据。

运维成本高

云原生为IT带来了很多便利，但同时云原生也让整个IT运维变得越来越复杂。一个K8S容器集群，至少需要部署高可用Master、网络插件、镜像仓库、日志服务，以及监控组件。即便辛苦把这些组件安装完成，也要面对后续每天各种运维、告警的处理，运维每天是各种的救火。

阿里云弹性容器实例ECI应运而生

有没有一种免运维、并且能够按需使用的安全的容器解决方案呢？阿里云弹性容器实例应运而生了。

阿里云弹性容器实例（简称ECI，Elastic Container Instance）是阿里云结合容器和Serverless技术提供的容器运行服务。通过使用ECI，在阿里云上部署容器时，无需购买和管理云服务器ECS，可以直接在阿里云上运行Pod和容器，省去了底层服务器的运维和管理工作。简单来说，一个ECI就是一个Pod，可以被K8s编排和调度。

阿里云弹性容器实例特别适用于突发的业务流量，或者短周期的任务运行。那么ECI和客户自己去购买ECS，在ECS里运行Docker有什么区别呢？最大的区别在于如果使用ECI，整个容器的运行时会将由阿里云来运维。

ECI有以下优点：

底层资源由阿里云托管，用户不再需要管理底层VM（虚拟机）。
复用整个阿里云的弹性计算资源池，保证充足的库存。
低成本，按秒计费，从Pod开始创建时收费。
启动快，秒级启动底层安全沙箱。
兼容性强，完全兼容K8s。

阿里云弹性容器实例采用社区的Virtual Kubelet方案与K8s集成，当集群内有Pod创建并调度到Virtual Kubelet时，Kubelet就会调用ECI接口，启动ECI。

ECI与业务系统的对接方式包括：

（推荐）通过阿里云容器服务Serverless Kubernetes（ASK）部署业务，提供无需运维的Kubernetes集群能力，底层Pod资源全部使用ECI承载。
（推荐）通过阿里云容器服务Kubernetes（ACK）部署业务，为ACK集群提供额外的海量弹性能力。
通过Virtual Node对接用户在ECS上自建的Kubernetes集群，提供方便快捷的弹性计算资源。
通过Virtual Node对接用户在线下IDC自建的Kubernetes集群，提供云上的无限弹性计算能力。
通过OpenAPI直接对接业务系统，低成本的随时创建或释放ECI业务容器。

ECI极速启动实例：6秒钟3000个容器实例

在2021年云栖大会现场，阿里云Serverless容器服务弹性容器实例发布了极速启动实例新特性。弹性容器实例在解决上述应用部署问题的基础上，创新的提供极速启动的产品特性。现场演示了在6秒时间内成功启动3000个ECI，并全部进入到Running状态。

阿里云是如何做到6秒钟启动3000个容器实例？

一方面，通过大量用户级别的创建历史数据，应用机器学习找出用户创建Pod的规律，通过预测预调度、资源复用等手段，节省ECI的调度、创建时间，同时使用了阿里云袋鼠沙箱容器作为引擎，辅以overlay网络、存储方案，将单ECI实例冷启动时间压缩到了3秒以下，针对袋鼠引擎后续会有专门文章进行详细的介绍，也敬请大家期待。

另一方面，在镜像拉取维度，通过镜像缓存把容器镜像做成快照，免去每次启动Pod拉取容器镜像的动作，例如阿里云的达摩院AI团队部分镜像可以达到几百G，如果按照传统方式拉取需要十几分钟，通过ECI的镜像缓存方案可以实现Pod秒级启动。